[ home | blog home | recent activity | guestbook | plugins i'm using (19) ]
I spent a good amount of time over the last few months migrating Miro on Windows to a new Windows build environment that uses Python 2.6.5 and Visual C++ 9.0 (part of Visual Studio 2008).
I landed the changes two weeks ago. Janet, Ben and I identified a couple of problems and sorted those out. Last week I got the Windows build box to produce nightlies without requiring any babysitting.
Yay!
Features of the new Windows build environment:
get_requirements.sh script that downloads
the versions of Python and libraries that you need automatically.
This also means that we can require Python 2.6 or later on all platforms for Miro. Therefore we can:
The one thing we still want to do is upgrade from gtk 2.16 to gtk 2.20. Bug 14037 covers the problems here. We're blocked by Bug 625972 in gtk.
I've written up instructions on setting up the new Windows build environment. It takes me about 30 minutes to do--mostly because it takes a while to install Visual C++ 9.0 Express. It's much easier to set up the new environment than the previous environment. When I first started at PCF a few years ago, it took me a couple of days to get the Windows build environment working.
For more details on the new Windows build environment, see the wiki page on WindowsBuildDocs.
Last night, I spent a few hours going through all the videos from PyOhio 2010, added metadata from the PyOhio site, added notes about video issues, and approved all of the videos except one which I'm talking with Carl about.
It looks like PyOhio 2010 was a really great conference: the talks are really great, you can feel the energy in the rooms from the people who attended, the questions are interesting, and the videos from the conference are fantastic. Also, I'm a huge +1 on using the headset mics--they absolutely make a difference in being able to hear the presenter throughout the video.
Here are three sessions I watched all the way through:
Sessions from PyOhio 2010 are in the PyOhio 2010 category. Take some time today to browse the sessions and watch the ones that interest you.
Also, I'm sitting on videos for two other conferences: DjangoConf EU and Kiwi PyCon. I'm hoping to get to them in the next couple of weeks. I did PyOhio 2010 videos last night because Carl needed someone to spot-check them to make sure the uploads were good.
There are two big hurdles to get through when starting on a bug before I'm in a position where I can fix it. I think the bulk of the time spent on most bugs is in getting through these two hurdles. If we could somehow reduce the amount of time and energy I spend on getting through the two hurdles, we can increase the speed that I can fix bugs.
Copyright 2008 Flickr user foxtongue
The first hurdle: what is the problem?
I think most people confuse the question "what is the problem" with "what's causing the problem". These are two distinct questions. The first one can only be answered by whoever reported the problem and this hurdle is a communication hurdle. I spend a lot of time trying to coach people into explaining the problem they have in a way that's coherent and complete.
It's not uncommon to get bug reports along the lines of "something's wrong and Miro doesn't work". I'm psyched someone has taken the time to report the issue, but there isn't enough detail here for me to do anything. In order for me to do something with this bug, I spend time walking the reporter through giving me enough details such that I have a good idea as to what the problem is. Because this requires communicating back and forth, this can take anywhere from a few hours to a few weeks to transpire.
Because it takes so long and requires me to ask 20 questions, I'm pretty sure most bug reporters find this phase very frustrating. Some question and answer volleys are really frustrating for me, too. I want to help--I just don't know what the problem is.
Assuming we get past that hurdle, then the second hurdle comes into play....
The second hurdle: what is the cause of the problem?
This hurdle is sometimes difficult because I can't reproduce the problem. I may not have the right context (e.g. "Problem XYZ happens to all people in Ecuador") or the right equipment (e.g. "Problem XYZ happens to people using Windows XP SP2 with video card Foo"). I'll read through code and work with the reporter to try to figure out the cause. Sometimes it works and sometimes it doesn't. When it doesn't it's really frustrating.
Most bugs aren't like that, though. I'm able to either reproduce the context and equipment or I'm able to use a reasonable facsimile. Then figuring out the cause is entirely on my shoulders and I can work through it like I do most things: code spelunking, research, Google searches, talking with co-workers, talking with upstream developers, ....
How can you help?
The following helps a lot:
Guess what....
This isn't specific to me or Miro! This is true of all FLOSS applications that you use: we're all working hard to build the best applications ever. Doing the above helps everyone.
This is the July status report for Python Miro Community. This site indexes videos from around the Internet related to Python. In particular, we focus on indexing conference session video and videos from our more prolific Python user groups.
In the last month, we've finished approving all the PyCon 2010 videos. They're all in the PyCon 2010 conference category.
I spent a few hours adding metadata to and approving videos from PyCon AU 2010. There are some really great ones--definitely worth looking at. They're all in the PyCon AU 2010 conference category.
PCF released a new version of Miro Community with some bug fixes and a widget that allows you to embed videos on other sites. I haven't played with that yet, but it sounds useful.
I'm still working on recategorizing things per Carl's suggestions from last month.
That's it for this status report. Any thoughts, questions or concerns--let me know.
I spent 20 or so hours over the last few weeks working through the moderator queue for Python Miro Community and making changes to the site. We've almost posted all of the PyCon 2010 videos--I think there are three or four more still in the queue including one of the lightning talks.
I've created a bunch of bugs in the Miro Community bug tracker for bugs that I've encountered and enhancements that would make the site and curation of the site better. Miro Community is a Free Software project, so I'm hoping to find free time to fix/implement some of those.
Carl Karsten is now a curator on the site--that makes two of us. He's been a huge help so far. Having someone to bounce ideas off of makes it a lot easier and he brings a lot of enthusiasm to the site. Right now we're coordinating things through email and we're tentatively going to use the pycon-av mailing list for PMC discussion. If we need to switch to another mailing list, then we'll do that.
At Carl's suggestion, we added a new category of categories for Python user groups. The three groups we have listed now are ChiPy (Chicago, IL), BostonPy (Boston, MA), and PyAtl (Atlanta, GA). The PyAtl videos are mostly from last year--I need to catch up with a PyAtl member to find out what's going on. There are only two BostonPy videos now, but the group is interested in doing more. The ChiPy videos are fantastic. Additionally, Pior from Montreal-Python is working on getting their video workflow working--I really look forward to seeing their sessions.
I've been tagging videos that I think are good for Python beginners with the tag "python-basics". At some point in the near future, we're going to move some/all of those videos into a Learning Python category. There's a large amount of decent introductory material for Python out there ranging from videos on YouTube to tutorials at PyCon. I think this category will make it easier for people new to Python to get their feet wet quickly and easily.
On a slightly related note, the Universal Subtitles project recently launched an alpha demo of their system. I'm looking forward to this project reaching a stable status since I'm planning to use it on PMC to add subtitle/transcription to all videos on Python Miro Community. The project is in Django and it's Free Software. If you're interested in this work, they sure could use the help.
That's it for this status report. Any thoughts, questions or concerns--let me know.
A few years ago, we switched from Trac to Bugzilla. After doing this, we discovered there were some things we really missed about Trac. The first was a unified timeline so that we could see what was going on in the bug tracker. The second was a roadmap that showed us, for a given milestone, where we were at.
I coded up both of these and over the years have made some adjustments. I made the timeline script available a while back, but I don't think I ever made the roadmap script available.
The repository with both of these is at https://git.participatoryculture.org/bugzillascripts/.
They work with our Bugzilla 3.6 instance. I haven't tested either on other versions or other instances.
If you use either or both, send me an email about whether it works for you, bugs, comments, ...
I was working on identifying and removing dead code in the Miro tree today when I decided to do some stats on the Miro codebase over the last bunch of versions.
| version | sloccount | .tar.gz size |
|---|---|---|
| 1.0 |
python: 44700 (94.91%) cpp: 1313 (2.79%) ansic: 790 (1.68%) xml: 264 (0.56%) sh: 30 (0.06%) |
12.3mb |
| 1.1.2 |
cpp: 58403 (58.71%) python: 39985 (40.20%) ansic: 790 (0.79%) xml: 264 (0.27%) sh: 30 (0.03%) |
13.4mb |
| 1.2.8 |
cpp: 58491 (58.53%) python: 40187 (40.21%) ansic: 796 (0.80%) xml: 265 (0.27%) sh: 196 (0.20%) |
14.6mb |
| 2.0.5 |
cpp: 73663 (58.74%) python: 49198 (39.23%) ansic: 1831 (1.46%) xml: 438 (0.35%) sh: 282 (0.22%) |
7.3mb |
| 2.5.4 |
cpp: 73808 (57.63%) python: 51631 (40.31%) ansic: 1874 (1.46%) xml: 432 (0.34%) sh: 328 (0.26%) |
10.0mb |
| 3.0.2 |
python: 52869 (95.73%) cpp: 832 (1.51%) ansic: 692 (1.25%) xml: 432 (0.78%) sh: 403 (0.73%) |
9.7mb |
| git master |
python: 53305 (95.98%) cpp: 832 (1.50%) ansic: 692 (1.25%) xml: 432 (0.78%) sh: 279 (0.50%) |
9.6mb |
There are a couple of interesting things here. First is that we switched to libtorrent in Miro 1.1. We had libtorrent code in the tarball in Miro 1.1 and removed it in Miro 3.0--that's the bulk of the cpp code.
Second, we did a ui overhaul for Miro 2.0. In doing that, we switched all three platforms to using gettext and thus only had to have one set of translations. We also ditched a bunch of binary data. That reduced the tarball size significantly.
Third, the number of lines of Python code has been going steadily up since Miro 1.1. This is the number I'm most concerned with. In adding more Python code version after version after version, we're adding more complexity and a larger domain of things to test. This adds to the maintenance work we have to do between versions, too.
We sure could use some help coding, fixing, maintaining, testing, documenting and translating.
If you're interested in helping, click this button:
I decided that having a Facebook account primarily for extending the marketing/publicity for the work that I'm doing wasn't worth it. I disagree with Facebook's "public by default" policy and the way they roll out changes to their Terms of Service and privacy settings. I think their recent change to make the ui for privacy settings easier to use (and not require a phd) is a good one, but not good enough for me to feel comfortable giving my data (or that of my friends and family) to them.
I'm also in the process of signing the copyright assignment statement to join the GNU Social project to build a federated system that gives people full control over their data. I'll be looking into building these features into PyBlosxom, as well.
I spent a few hours with the Python Miro Community site today re-applying the template changes I made to the theme to the new version of the theme. Miro Community has released two versions since I tweaked the theme, so I was playing catch-up. I'm putting my edits into version control this time around so I don't lose them again (stupid stupid stupid).
One of the things I want to do with Python Miro Community is to build playlists of videos covering a specific theme for helping people come up to speed with those areas: testing in Python, basic Python programming, advanced Python programming, ... I've been faking this using tags, but it's pretty suboptimal because I can't control the order the videos get listed in on the tag listing page. Dean created bug 12627 for implemnting playlists/series. This would also fix the problem I have where YouTube duration maximums force a single "video" to span several YouTube urls and thus be several separated videos. Anyhow, looks like that isn't going to get implemented for Miro Community 1.0.
I started slogging through the queue. We've got 80 videos or so in the approve/reject queue right now. A bunch of them are PyCon 2010 related. A bunch are from Carl's blip.tv feed and are from ChiPy and other things. 50 or so are from a Plone feed that Nate Aune sent me. I'm going to make a concerted effort to get through the queue over the next couple of weeks.
Even though I'm behind in the queue, I encourage people to submit new videos. Some of the best material comes from Python user groups--I'd really like to see more groups videoing their sessions, posting them online, and submitting them to PMC. Don't let ChiPy and PyAtl outshine everyone else!
You can find Python Miro Community at http://python.mirocommunity.org/.
Quickly is an application that makes it easier to start new software development projects by filling in a lot of the skeletal structure from a set of templates. I've read about it a bunch on Jono's blog in the context of his push for "opportunistic developers".
Chris Webber and I have been throwing together web applications most of which have the same basic structure: WebOb, Jinja2, simplejson, and routes with some glue and stuff in between.
I spent some time building a Quickly template for this structure. The results of this are at http://gitorious.org/quickly-webber-app.
It was kind of a pain in the ass. There's no docmentation that I could find on creating templates for Quickly, so I had to look through the ubuntu-project template and read through the Quickly code. Even then, I bumped into a few gotchas.
~/quickly-templates/ directory rather than as a
project and schlepping things in and out like I did
I was using the Quickly that comes with Ubuntu Karmic which is 0.2.6. Ubuntu Lucid has a newer version, but I didn't want to fiddle with trying to get it to install on Karmic given that it's got dependencies that aren't readily available in Karmic.
After talking with Chris, he suggested I redo it with Paste templates. There's a good explanation at http://pylonshq.com/docs/en/0.9.7/advanced_pylons/creating_paste_templates/. It'd be interesting to see if I could build a set of templates that works with both Quickly and Paste.
Anyhow, the project is there if it's interesting to anyone. Email me or comment below if you have questions, comments, concerns, whatever.
Update 5/2/2010 - Didier (Quickly dev) says there is documentation for creating templates at http://www.didrocks.fr/index.php/post/Build-your-application-quickly-with-Quickly%3A-Inside-Quickly-part-6.
I applied to be a member of the GNOME Foundation two days ago and today I was accepted. I'm excited and happy that I was accepted. I hope that my work on GNOME Miro Community helps the greater GNOME community.
We pushed out Miro 3.0 today. There are still some minor things to do like Ubuntu packages (I'll work on that Friday), version updates on the web-site, .... Still, it's really great to finally get the release out the door.
This release has some great features in it:
Also important, but not something you would see direct evidence of, we did a lot of work on infrastructure and process for developing Miro:
We're working hard to make sure that this and future releases are good quality releases. We're working hard to make sure that the four of us can keep pushing Miro in new directions and provide better support for Miro users. We're working hard to do more with less.
We're very excited about this release--it feels really good.
We've also already started on Miro 3.1 development. You can follow the roadmap here.
PyBlosxom 1.5 rc1 was released a month or so ago. Since then I haven't had much time to finish things up.
Spaetz kindly did the work to move PyBlosxom source code from svn on SourceForge to git on Gitorious. The plan is to move development to Gitorious and the web-site, documentation, bug-tracking, and things like that to a site on my server bluesock.org.
This enables people to fork PyBlosxom trivially and make the changes they need to make to get PyBlosxom working for them. This will result in more experimentation and work being done and reduce the problem of me and my decision making being a bottle neck in future PyBlosxom development.
The other big change that's happening partially in the PyBlosxom 1.5 timeframe and partially in future versions is the ecology for plugins. Previously, I ignored them and spent my time on PyBlosxom core stuff. Ryan was maintaining the plugins, but the infrastructure we had for plugin maintenance sucked. Going forward, plugins will fall into two categories:
The plugins that are currently in the contributed plugins pack will be split into those two groups.
PyBlosxom 1.5 is waiting on some more documentation changes, some more plugins work, and now some project infrastructure changes. I'll probably do another release candidate soon and suggest people start using that.
If you're interested in helping out, come hang out on IRC on freenode.net in the #pyblosxom channel. The conversations have been interesting over the last couple of months and have been instrumental in work getting done.
PyCon 2010 is over and the PyCon AV crew is working on taking the video they've recorded, editing it, and posting it. As they post it to the Pycon blip.tv feed, I'm pulling it into Python Miro Community. You can keep track of my status here (RSS).
I sent an email to the Cambridge Python Meetup (Cambridge, MA, USA) asking if they still record video and if so, where it gets posted.
Nate Aune sent me a link to the PloneTV feed. I'm in the process of pulling those videos in.
One thing I've noticed while curating Python Miro Community is that the quality of the image and audio make a huge difference in the usefulness of the video after the event. It's a huge project with a lot of finicky bits to reliably create great video.
Many many props to Carl Karsten, the PyCon-AV team, and all the other people out there doing this work. It allows these presentations to live beyond a moment in time and reach a much larger audience.
If you're one of the lucky people going to PyCon 2010, you might want to spend some time coming up to speed on some of the talks being given.
Interested in the GIL? David Beazley is giving a talk on the inner workings of the Python GIL. He's given several GIL-related presentations before: Asynchronous vs. Threaded Python, Mindblowing Python GIL, and Changes to the GIL in Python 3.
Interested in documentation? Wesleay J. Chun is giving a talk on writing books using Python and Open Source Software. This will likely talk about Sphinx. Take some time to watch Brandon Rhodes talk about Sphinx at PyAtl.
Interested in PyPy? Maciej Fijalkowski is giving a talk on the speed of PyPy. Take some time to watch the PyPy status talk from PyCon 2009.
Don't go to PyCon unprepared!
Today I'm releasing Python Miro Community. This site is a Miro Community focused on Python. It brings together videos from Python conferences, local user groups, screencasts, and tutorials.
I'm working on it in my spare time because:
This site helps on both fronts. The first in that it collects video into one place without re-hosting it. The second in that I'm curating the site and through better descriptions and tags, the video becomes more findable.
It's not finished--it's an ongoing project that I'll continue to work on. My ultimate goal is to connect with Python video producers like Carl Karsten (whose work is phenomenal), conference A/V people, local user group A/V people, and all those people out there making screencasts, tutorials and project status videos to make sure Python Miro Community stays relevant and continues to helps creators and consumers.
It's free. I'm doing this in my spare time, Participatory Culture Foundation (the non-profit behind Miro) is providing the server and resources to host the site, and the video on the site is available for free on the Internet.
Spend some time today to take a look at the site, browse the PyCon 2009 and DjangoCon 2009 videos, spend some time honing your Python skills with either the Python basics or Python advanced tracks, follow along with the ChiPy or PyAtl local user groups, and see what's out there.
Love it? Hate it? Let me know in the comments.
Thank you to Carl Karsten and Steve Holden for their help pulling this site together!
PyBlosxom uses Sphinx for documentation
now. I was having problems with using -- for em-dash and it not
showing up like an em-dash in the HTML output.
The docutils FAQ says to use the actual unicode character for emdash. I don't really want to do that because I'm not sure about what happens when the source files are opened up by a non-unicode-friendly text editor.
Turns out that doesn't matter because Sphinx allows -- for
en-dash and --- for em-dash. Is this something that should
get added to the Sphinx documentation?
Today I read You can't crowdsource software. The title sums up what it's about.
I've had this experience with Miro. We occassionally get patches from non-PCF people but most of the work is done by PCF developers. We've spent a lot of time and effort over the last few years on getting more code contributors and reducing the barriers to entry. We haven't had much success.
However, there's a lot of other "stuff" that goes into developing an application and the article only focuses on code. Some of this "stuff" can be successfully crowdsourced without a lot of effort. For example, Miro crowdsources all of our strings translation work through Launchpad.
I work on another project called PyBlosxom. We have a core group of developers (right now this is me) who do the bulk of the core code work. I do some plugin work, but the bulk of the plugin work is done by users of PyBlosxom many of whom have never touched the core code. For PyBlosxom, plugin development is crowdsourced.
The article suggests that it's a waste of time to help bring new contributors come up to speed and contribute because they often don't contribute much. That conclusion really concerns me. How can we get more people helping out if we're not working on getting people to help out?
Jono Bacon wrote an article titled Project Awesome Opportunity which talks about a few projects that are reducing the barriers to contributing and making it a lot easier. It's very Launchpad-centric, though.
OpenHatch is a startup working on building the next generation of contributors and connecting contributors to projects that need help. They're wrestling with how to effectively fix these problems, but without tying the fix to a project development silo (e.g. Launchpad, GitHub, ...). I think that's really important.
I think systems like these will reduce the effort in getting contributors and make it easier to crowdsource code contribution.
And if you, dear reader, are looking for a project to help out on that's written in Python and need someone to mentor you, let me know.
February 5th, 2010: I should clarify I think the article is fine. I don't think the conclusion that code contribution doesn't crowdsource well is poorly formed or anything like that. Just that the implications suck.
Spent a while figuring out how to get Miro to handle media keys in Gnome. My current understanding (and this could be entirely wrong) is that as of 2.18, Gnome handles the multimedia keys. In order for your application to respond to multimedia keys, you have to connect to the signal through dbus.
My biggest problem is that my web searching revealed a lot of bugs, but no documentation. I did finally find Handling multimedia keys in GNOME 2.18 and then worked out the rest. I still have no clue where to find the documentation for it.
Here's what I got working:
import logging
import dbus
from miro import app
class MediaKeyHandler(object):
def __init__(self):
self.bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
self.bus_object = self.bus.get_object(
'org.gnome.SettingsDaemon', '/org/gnome/SettingsDaemon/MediaKeys')
self.bus_object.GrabMediaPlayerKeys(
"Miro", 0, dbus_interface='org.gnome.SettingsDaemon.MediaKeys')
self.bus_object.connect_to_signal(
'MediaPlayerKeyPressed', self.handle_mediakey)
def handle_mediakey(self, *mmkeys):
for key in mmkeys:
if key == "Play":
app.widgetapp.on_play_clicked()
elif key == "Stop":
app.widgetapp.on_stop_clicked()
elif key == "Next":
app.widgetapp.on_forward_clicked()
elif key == "Previous":
app.widgetapp.on_previous_clicked()
def get_media_key_handler():
try:
return MediaKeyHandler()
except dbus.DBusException:
logging.exception("cannot load MediaKeyHandler")
If you see problems with this, let me know so I can ammend the code.
I keep seeing people say things like, "I'm not a programmer, so I can't help."
I think this is a common misconception about Free Software. Free Software empowers you. Let me say that again...
Free Software EMPOWERS You.
Miro is a Free Software project and like all Free Software projects, there are a variety of ways that you can be involved. By being involved you are taking the responsibility to help solve your own problems.
You can test nightly builds and release candidates.
You can submit bugs and help us triage and fix them.
You can send in patches. Patches can be for code, documentation, packaging, ...
You can package Miro for other distributions.
You can translate strings.
You can tell your friends and family about Miro and help them get setup. You can blog about Miro. You can dent about Miro.
You can adopt a line of code. This helps fund ongoing development. If we had more funds, we could have more paid developers.
Miro is built and maintained by all of us working together contributing our time and resources. There are features to be implemented, bugs to be squashed, systems and software to integrate with, standards to develop--the future is great with possibilities. There's a lot of stuff that can be done and you can help the Miro community do it.
We've been working on subtitle support for Miro in the subtitle branch. Yesterday, Ben merged the changes into the master branch. As of this morning, nightly builds have subtitle support. Yay!
There are still a few things to implement and the code hasn't had much of a chance to settle. Also, there are still some things I think should get refactored and it's likely we'll be tweaking the interface going forward as we use it more.
Still, it's good to have landed the bulk of this feature. It's probably not wildly useful yet, but it gives us some ground work towards building better subtitle distribution/creation infrastructure going forward.
We've been working on reducing the complexity of the code for Miro 2.6. We've done this in a few different ways and I want to summarize them here.
moved binary kit stuff to separate repositories
This dropped the size of the git repository for miro a lot. Cloning the repository is much faster now. Plus it's easier to build Miro on Windows and OSX from the source tarball.
moving libtorrent out of portable
On Linux, this allows us to rely upon Linux distributions to have packages for libtorrent (the Rasterbar version) and the Python bindings. We don't need to compile libtorrent as part of the Miro build process anymore. That dropped the build time like a rock, reduced the tarball size, and removed a bunch of issues from configuring and compiling Miro on Linux.
removing sorts.pyx and fasttypes.pyx
Removing these allowed us to remove the build dependency on Boost. That removes a bunch of assy code we had in the setup.py file. This also reduced the time it takes to build Miro on Linux.
adjustments to setup.py to be more whiny when things are missing
I added some code to the gtk-x11 setup.py to make it clearer when it's missing build dependencies. I then tested this on Kubuntu Karmic, Fedora 12, and OpenSUSE 11.2. Miro will still try to run if it's missing things--I'll look into this soon.
updated gtkx11 build docs
I went through and updated the build recipes in the gtk-x11 build docs page. I updated the recipes for Ubuntu Karmic, added recipes for Fedora 12 and OpenSUSE 11.2 (though it won't work because I couldn't find a libtorrent rasterbar package), and removed a bunch of old recipes that would never work. I'm planning to do Gentoo and some other distributions next.
I updated the build and runtime requirements lists, too.
removing xine
This hasn't been done yet, but it'll happen soon. This will remove some build requirements and it'll make our lives easier since we'll only have to support one renderer on Linux. Supporting two takes a time and effort and we're only doing a so-so job of it. Better to cut xine loose and focus on gstreamer. I'm sorry that this will affect some people. I'm hoping to rework the code so that additional renderers can be released as separate packages like I did with frontends.
conclusion
We're focusing on reducing the complexity of the codebase and build requirements to make it easier for new people to pick it up, build and contribute. If there's anything else we can do on this front--or better if there's anything YOU can help us do--let us know.
About a week ago, Joe contributed a patch to disable the screensaver on KDE when Miro is playing fullscreen. I don't run any systems with KDE on them. I'd love to get some help testing this patch so that we can include it in the next release of Miro.
The bug for this work is http://bugzilla.pculture.org/show_bug.cgi?id=3067. The patch is at http://bugzilla.pculture.org/attachment.cgi?id=1980.
Let me know whether this patch works or doesn't work for you either in the comments of this blog entry or in the comments of the bug.
Miro uses libtorrent-rasterbar
for bittorrent downloading. We had a copy of the libtorrent source code
in the portable section of our repository. Miro would compile
libtorrent as a Python extension along with all the other stuff to build
Miro binaries. Not any more.
Luc is almost done carrying my changes over to OSX 10.4, but as of today,
libtorrent-rasterbar is no longer in the portable section
of our repository.
What does this mean?
For Windows, a clean build on our Windows build box went from taking enough time for me to make dinner, eat dinner, and then completely forget what I was working on (26 minutes) to 4 minutes. In my Windows XP vm, a clean build went from 8 minutes to 1 minute. Plus I fixed the unicode problems Miro had with Windows and libtorrent and updated Miro to use libtorrent 0.14.6 on Windows.
For OSX, a clean build on my mac mini running OSX 10.5.8 went from 17 minutes to 1 minute. Plus I updated Miro to use libtorrent 0.14.6 on OSX, too.
For gtk-x11, libtorrent is now a required system package. Miro will no longer compile its own libtorrent if you don't already have it installed. I'm pretty sure that most modern versions of the major Linux distributions have packages for libtorrent-rasterbar and the Python bindings.
We have a couple of other changes that affect the project structure almost done. I'll blog about them as they finish landing.
11/4/2009 - This is completed now. Many thanks to Luc who sorted out the issues I was running into with compiling libtorrent on OSX 10.4 with Boost 1.35.0.
I use a four space indent which causes problems when indenting
if statements that span multiple lines. For
example:
if (a
and b
and c):
if_block_here
The problem is caused because if is two characters
and therefor if ( is four characters--which matches
the four space indent. I end up with code where I can't easily
distinguish if statement from the if block.
After talking about it with Paul and Chris and working out what the specifics of the problem are, I decided to use double parens. The above with double-parens looks like this:
if ((a
and b
and c)):
if_block_here
That satisfies PEP-8, doesn't change the semantics, and fixes my problem. It is a little goofy to use double parens, but it's a good enough fix until I get around to fiddling with the code that does automatic indentation in python-mode.
I'd be interested in other ideas that don't involve using \
at the end of lines if they're out there.
I finished up the work for converting our svn repository to git and pushed the whole thing to the server. You can follow along at https://git.participatoryculture.org/miro/.
I'll be spending the next week or so updating code, infrastructure, and documentation to reflect the change.
We're switching the Miro repository from svn to git. This frees us up considerably and will make development life a lot easier for us. We chose git over other dvcs systems because most of us were already using git-svn to access svn and we're already using git for Miro Guide, Miro Community, Miro Fullscreen and other projects.
For the last week or so, I've been converting the Miro svn repository to git. It's taken a long time because I ran into several complications:
Hopefully, I'll be done in the next day or so. Once I finish, I'll push the new git repository to a public space, have the other devs run through it for issues, post a message about it on the develop mailing list and then I'll start work on changing build scripts and other things like that to use the git repository rather than the svn one.
One thing that's happened as a result of this work is that I've really come to appreciate git internals and how it's all structured. I have no idea how Bazaar and Mercurial structure things, but git's pretty neat.
Update 8/17/2009: My math was way off. I've got another 50 tags to go at 20 minutes per tag that's at least another couple of days.
We released Miro 2.5 a couple of weeks ago and it was a messy release which resulted in a Miro 2.5.1 a day or two later and a Miro 2.5.2 a few days after that. It sucked. I wish it had been better.
Before a release has happened, a messy release looks like any other release: development has wound down, lots of bugs have been fixed, a bunch of new features have been implemented, testing is going well, people who have looked at the nightlies and release candidates like the new features and haven't encountered any issues, ... Then we decide to pull the trigger and push it out.
It's only when a release is out that the messy release rears its ugly head and the obviousness of its messiness is revealed. Usually this is made abundantly clear by abusive emails from people who encounter problems with the release, become frustrated, and express themselves with abusive vitriol aimed at me and all the other people who worked hard on the release.
It's at this point, I bite the bullet, prepare for the world of pain I'm about to get involved in, and try to reach out to as many people as I can, gather information to identify the issues so that we can fix them, and provide support to people who are encountering problems to enable them to get through them.
So what the hell happened with Miro 2.5?
Miro 2.5 started out with a big flaw: there was no upgrade dialog showing when Miro was transforming the database from the old style to the new style. If you have a small database like mine (8 mb), you'd never notice. People who had huge databases would launch Miro 2.5 for the first time and ... seemingly nothing would happen for minutes. The person would assume Miro isn't starting, would kill the process, and then try again. At this point, Miro would see a wedged database and wouldn't start. We think there were on the order of 30,000 downloads at this point and we had maybe 50 people who had problems.
We recognized the problem and we kicked into emergency mode. Janet and I worked the GetSatisfaction forums, blog, and identi.ca. Ben poured over the incoming data, made a few fixes and put in a progress dialog. We pushed out Miro 2.5.1. Janet and I went through and talked to each user who had problems to help them unwedge their database and get back to a working Miro.
A day or two later, we found another couple of problems. I made some fixes and pushed out Miro 2.5.2. Then I wrote a script people could run to re-download data that was lost. Dataloss totally sucks. We did everything we could to help alleviate the problem after we found out it was there.
There are still a bunch of people for whom Miro doesn't work. I'm talking with a few of them. Others have given up. It's always been the case that there are people for whom Miro doesn't work and we do what we can to figure out the causes.
And that's where we are now.
Going forward, we're going to figure out how to better test Miro release candidates. We thought that 600 people would have fleshed out most of the issues, but it seems that there are classes of people whose usage patterns aren't reflected in our testers and testing. If you can help us with testing, we'd love to have you. You will have a direct impact in making Miro better.
Going forward, I'm going to work on making it easier for Miro to help people identify problems and let us know. I'd also love to get some help fixing Miro so that it doesn't lose data when things go wrong. Code contributions would help a ton here.
Going forward, I'm going to ask for help more often. There are only 4 PCF developers and we're spread very thin between Miro, Miro Guide, Miro Community, and the other things we're working on. We need your help. This isn't a new situation. What is new is that I'm going to do a better job making it explicit what I need help with right now.
I love working on Miro. I love what Miro is doing for people and for communities. I love our mission. I need your help to help me help you. Miro is your project as much as it is mine.
I hope the initiatives we're working on will eliminate messy releases in the future.
Miro is nearing a 2.5 release candidate. There are only a couple of things we're waiting on now like a VLC 1.0 release. I'm hoping for a release candidate as late as next week and a final a week or two after that depending on how well the release candidate works for people.
If you're a Miro translator, the strings are frozen and we sure could use your help getting up-to-date accurate translations for Miro 2.5. If you know someone who's done Miro translations in the past, let them know that we're rapidly approaching the 2.5 release.
As a reminder, Miro 2.5 is the "trunk series" on Launchpad. Don't translate the Miro 2.0 series--changes there won't be carried over to trunk unless you do it yourself. The Miro trunk series translations page is here.
Now for the gripe. In the last week, Launchpad did an update which changes the translations pages and they no longer tell you the last updated date for individual translations. That's a real drag. I used that field to figure out whether or not to export translations from Launchpad and import them into Miro and to watch translation activity. Grumble grumble grumble.
I'm subscribed to all downstream Miro bugs in the Fedora bug-tracker. I'm also subscribed to all downstream Miro bugs in the Debian bug tracking system. It helps a lot to triangulate issues with external component versions and the myriad of other problems that come with developing an application that runs on Linux distributions.
Today, Rudd-O, who I've never met, ranted on the state of the Miro codebase in bug 494505 in the Fedora bug-tracker. I responded with this https://bugzilla.redhat.com/show_bug.cgi?id=494505#c13.
I thought I should blog about that since I really don't blog enough about the whos and the whys and the hows of Miro development.
After Miro 1.2, we decided to embark on some serious rewrites to fix big problems with the way Miro was structured. Thus each major version since Miro 1.2 has involved signficant overhaul.
Miro 2.0 saw a re-write of the ui. In doing so, we rewrote the Windows platform code which used to be a XULRunner application but is now a Python application using GTK. The ui rewrite fixed a lot of internal codebase problems, but the primary use case was to fix performance problems when displaying feeds with lots of items in them. Display isn't perfect, but it scales a lot better now. As a side note, it's not that we didn't like XULRunner, it's that we wanted to merge the windows and gtk-x11 platforms to make it easier to develop going forward.
Miro 2.5 (not quite out yet, but hopefully soon!) involved a re-write of the data storage code. It is a good thing to do in general, but the primary use case here was to fix performance problems with startup. No longer does Miro need to load the whole database to load the ui; now it can do it in parts. This speeds up Miro startup for a lot of people especially those with large databases. As an added bonus, the database is a regular relational database which other programs can access to see Miro managed media and metadata.
We don't have plans for the next version yet, but there's still a lot of stuff to re-write and make better. The downloading code needs refactoring. The feedparsing code needs good regression tests and once we have good regression tests, it should get refactored. There's a lot of code that needs to be documented and cleaned up. We need to add support for new standards and specifications. We need to add support for really important features like subtitles. We want to build a plugin framework allowing people to extend Miro in their own ways to meet their needs.
That's what we're working on, but there's no way we can do it all at once. We could use your help. If you can't contribute code, contribute funding for someone else to dedicate the time to work on code.
We are all Miro users. We are all Miro evangelists. We are all Miro testers. We are all Miro developers. Miro was made by you and me for you and me. Long live Free Software and Open Video!
When I upgraded from Intrepid to Jaunty, I noticed that git svn
things were painfully slow. I had looked into this before, but
couldn't remember how I found the answer or what it was. After skimming
through thousands of lines of IRC logs, I re-rediscovered what I discovered
the first time.
rm -rf .git/svn git svn rebase --all
I found it at this site (oebfare.com).
I spent a few hours throwing together a new tags plugin that makes use of the new commandline features of code in PyBlosxom trunk (which will be PyBlosxom 1.5). Then I spent a while adding tags to all my entries.
I'm still mulling over my choice of tags, but I imagine I'll hone it into a set I'm happy with over time.
Also, I used :: as a tag separator, but I think I'd recommend
something that doesn't require a shift key to enter. Perhaps ;; or //.
Tag information is stored in two dicts that are pickled and thrown in a file. It seems to be pretty fast to load for my blog (~500 entries). I picked pickle because it was easy, but if it turns out to be a problem, I'd be game for other storage formats.
I've been waiting for tags support before I did more blogging. Now that I've got tags support, I plan to move my work blog here. That'll make things easier and get me off WordPress.
I finished up some additional work and I'm at a testing stage for PyBlosxom. I want to do some more testing and some documentation then it'll be ready for testing releases.
Also, I spent a couple of minutes upgrading my blog to use 1.5 in trunk. Bumped into bunch of weird issues with the comments plugin, but otherwise it was really smooth.
It's been a long time since the last status. PyBlosxom 2.0 had been stagnating for a year and I decided to move it out of the way, put it out of its misery, and start new progress with the PyBlosxom 1.4.3 tag. I scaled back the vision and now I'm working on PyBlosxom 1.5.
I've pulled in some of the changes that were destined for 2.0 and added some new ones:
In the very near future, I plan to overhaul the website and fix project infrastructure issues.
That's where things are. Hoping to have an April release of PyBlosxom 1.5.
The sordid story
I, too, was contacted by Packt Press to review Expert Python Programming by Tarek Ziadé. I finished reading the book months ago, but didn't get around to writing the review.
Then I saw the review from some person I don't know and the reply from Tarek. Tarek then went on to work through all the "bugs" and put out a new revision of the book. I still didn't get around to writing a review.
Then I saw Orestis' review. This review is pretty comprehensive. I think it covers a lot of the things I was going to say, so I'll just fill in the gaps.
The short review
The book is pretty good. It's really aggressive in that it's trying to cover a lot of ground and as such some of the chapters don't get very deep. Even so, I think the book does achieve it's mission:
There are two things I wish had been different. The first is that every chapter should have ended with a "further reading" section that listed books, magazine articles, urls and other resources that further cover the topic. That would have really helped people the book is targeting.
The other thing I wish had been different is that many of the urls used throughout the book are "fragile": they're really long, have a lot of funky bits in them, and if the owner of that site moves anything around, the url becomes a dead link. I'm not really sure how to fix this, but maybe books should have bit.ly-like links in them that redirect through the book's web-site to the url in question. When the resource at that url goes away, then the book author can change the web-site to summarize what was there or provide a different link.
If you're interested in the book
If you think that's interesting, check out the Tarek's blog entry about the book and sample chapter.
If you still like it, then it's probably worth buying or waiting for Packt Press to send you an email to review it. ;)
I use VirtualBox OSE for virtualizing test environments for Miro development. I built a Windows XP vm a year ago and when I did it, I put it on a virtual disk that was 8 GB which turned out to be waaaay too small for my needs. It's non-trivial to build a Windows build environment for Miro so I really wanted to clone the partition to a new virtual disk that was a lot bigger, then resize the partition rather than create a new virtual disk and reinstall and set everything back up.
I pretty much did that this morning in a couple of hours.
First thing I did was download the LiveCD of Clonezilla (version 1.2.1-23) and the LiveCD of GParted (version 0.4.1-2).
Second thing I did was create a 25 GB virtual disk in VirtualBox.
Then I attached the new virtual disk to the winxp vm that I had. Thus it should show up as hdb.
I booted into the Clonezilla LiveCD, cloned the old virtual disk to the new one keeping the partition sizes the same and making sure to copy over the MBR, too.
I switched around the virtual disks attached to my winxp vm and booted into the new virtual disk--worked great!
I booted into the GParted LiveCD, launched qtparted and grew the NTFS partition so that it used the whole virtual disk.
Then I booted into the new virtual disk. It did an NTFS disk check on startup which I thought might indicate the process didn't work right. Disk check passed, Windows XP booted and everything worked as well as I expected it to.
If you're writing code like this:
try:
foo = somevar.getBlah()["xyz"].split(".")[-1].decode("ascii", "replace")
except:
pass
Please stop! You're killing the rain forest!
In Miro, we've got long strings that are displayed in the user interface. I think the code that defines these strings is messy and hard to parse. For example:
def some_func():
description = _("""\
This is a really long description that has multiple sentences and a few \
things that need to %(getfilledin)s and it goes on and on and on and on \
and I'm not really sure what's the best way to format it so that it's happy \
in editors and easier to parse.""") % {"getfilledin": blahblah}
PEP-8 doesn't address this, which is fine. I was curious to see what other projects do.
I was at OSCON last week and met many people some of whom I've known for several years (Ted, Steve, ...). I also met a bunch of people who I've followed for many years and some people I've worked with when doing the Firefox 3 work I did. It was really exciting to be there. I didn't attend any keynotes or sessions, but the conversations I had were well worth trekking all the way to Portland, OR and back. I also got to spend a week with my sister who lives in Portland.
On the flight there and back, I worked on PyBlosxom. I mostly concentrated getting better acquainted with nose and using nose and coverage to help guide my testing efforts. The results were phenomenal. I increased the test count from 53 or so to 207, I increased coverage from some low number to 57% and I discovered and fixed a bunch of bugs. Because I switched to git over svn, I was able to commit locally and manage the work I was doing. All very exciting.
Miro is coming along very nicely. We took the plunge to ditch the previous frontend for a new one that has fewer layers of indirection. The results so far are encouraging--I think it was absolutely the right thing to do. Incidentally, I blogged about OSCON on my Miro devblog.
In the last few months, I've thrown together several web-sites using werkzeug, sqlalchemy, and mako. I really like this stack since it doesn't involve a lot of infrastructure and the number of files and "things" involved is pretty small. I think this is going to be my preferred stack for webapps going forward.
Just before OSCON, I signed up with identi.ca. It's my first micro-blogging account. Mostly I wanted to see what micro-blogging was like and follow other OSCON attendees. OSCON had a _lot_ of back-channel conversations going on.
Just before signing up for an identi.ca account, I met Jack, who lives around the corner from where I live. I wish I had made the effort to contact him years ago.
I think that's about it. It's been an interesting few months.
The company I work for is looking to hire a few able Python developers. Instructions and details about the job are on the PCF jobs page.
This is the best job I've ever had. I get to telecommute which really works for me. My co-workers are all able fantastic people. The mission is really important and affects everyone. The work that we're doing is FOSS and we're working with and contributing to other FOSS projects. I've covered the board in terms of projects from bug fixing, to adding enhancements, to debugging upstream components, to Ubuntu packaging (which I need some more practice with), to test systems, to Firefox 3 patches, to Firefox plugins, ... I've also had my hands in Bugzilla adjustments, infrastructure, build systems, ... It's been challenging and interesting ever since day 1.
I've also been meeting a lot of people I otherwise wouldn't have met: Chris Blizzard and John Ressig at Mozilla, SJ at OLPC, Holmes Wilson at Downhill Battle, Asheesh at Creative Commons, and others. It's exciting.
That's my experience at PCF in the last 6 months. If you're looking for a telecommuting Python development job, think about applying.
I spent almost my entire January adding better support for RSS/Atom enclosures to Firefox 3. I wrote more detail on my work blog.
I overhauled the PyBlosxom web-site so that it's now being statically "compiled" using PyBlosxom's static renderer. The whole thing is checked into SVN, too. That's a huge improvement from the previous situation, but the web-site could use user-interface and navigational work.
In doing that, I did a lot of futzing with static rendering using the code in trunk and fixed some issues. I also thought through the filelist implementation and re-worked it so that it handles sorting and truncating better. The results are really nice and I think it fixes all the major problems previous versions had.
GHOP was a big help. PyBlosxom had several tasks that were worked on and the results speak for themselves:
It was a huge help that these people did for PyBlosxom. I haven't fully absorbed their work yet, but it should happen before PyBlosxom 2.0 is released. Many thanks to those of you who helped out and many many thanks to Google and the GHOP, PSF, Titus, Doug, Georg, Leslie and all the others who helped make this possible. Thank you!
There are a few big things that still need to be done for PyBlosxom 2.0. I'm moving through it slowly and methodically. I was hoping to have it done by the end of December, but I'm thinking now it's going to be the end of March or thereabouts.
I mothered the Miro 1.1 release earlier today. Then I decided to push out PyBlosxom 1.4.3 which I have been sitting on for a month. Then after talking with "paulproteus", I decided to go for the hat-trick and released Lyntin 4.2 as well.
w00t for releasing three software thingies in one day! Boo for sitting on two of them for extended periods of time.
I released PyBlosxom 1.4.3 with better support for WSGI and Paste and
support for template variables of the form $(foo). More
information on the
PyBlosxom web-site.
It's the last release I do for Lyntin. It's got some new functionality, some bug fixes and I upgraded the license to GPL v3 or later. More on the Lyntin web-site.
It was a pretty wild year for me. I had a massive health crisis at the beginning of the year, wrote an almost-working compiler for a functional language using SML targetting SPIM, finished up grad school, got married, landed a job at Participatory Culture Foundation, made a lot of new friends, mentored a GSoC project, helped out with GHOP, started the big push for PyBlosxom 2.0, released a new version of Bee Careful, Marvin under a CC BY-NC-SA 3.0 license and submitted my first patch for Firefox 3.0.
I started the Nomadic Telecommuting Herd which has regular meetings, but hasn't extended beyond Chris and I, yet. I'll push this more at some point in the spring when it's more fun to go outside.
I also joined a few projects that I haven't been able to get to yet like the Python docs project and Geyser. I'm interested in helping out both of them, but haven't found the time yet.
This year I want to tame the firehose, get some good work done, participate more in other projects, possibly learn C++ and reach out to other people in the area (Somerville, MA, USA) to get together and hack more. I'd also like to get a new laptop, but the longer I wait, the better the possibilities become.
I was throwing together a patch for Firefox 3 and needed to add some files to CVS but I don't have add privs. If I don't add the files, then they don't show up in the diff. After a Google search, I bumped into fakeadd which tweaks the Entries file so that the new files show up in the diff. No clue if that's a good thing, but it certainly fixes the problem I was having.
I'm working on improving the PyBlosxom testing situation and in the process
of doing that ran into a problem with
nose (version 0.10.0) and
coverage (version 2.77).
Both installed with easy_install.
When running:
nosetests --verbose --with-coverage --cover-package=Pyblosxom --include unit nosetests --verbose --with-coverage --cover-package=Pyblosxom --include functional
I bumped into the problem described here (nose.python-hosting.com) and here (code.google.com). The solution is to either:
coverage.py from /usr/bin, or
/usr/bin/coverage.py to /usr/bin/coverage
I work for Participatory Culture Foundation as a developer on the Miro internet video player.
Today we released Miro 1.0. For most of the projects I've worked on, the 1.0 mark is exciting to reach, but also somewhat of a downer because it really requires you to hone the list of all possible things you could do down to a small finite list. Inevitably, there are things people will want to do that 1.0 doesn't do. Still, it's a huge milestone for the project. We're already working on post-1.0 development and making changes to decisions that didn't turn out as well as we had hoped.
A good portion of the work we do is in Python with lots of interaction between Python and libraries written in C and C++. For example, we use a lot of Pyrex to speed up critical sections.
Miro is a great product to continue to push open standards for video distribution and consumption on the Internet. I regularly watch GoogleEDU videos through Miro and I'm hoping other Python-related channels will be available as well. At some point, I'd like to create my own Python-videos channel and aggregate good Python-related video content. There's a lot of screencasts and tutorials out there....
Work has been pretty busy. I've been doing release manager stuff,
working on Gutsy packaging issues, puzzling over an intermittent problem
between the sun-java6-plugin and Miro, working on a Firefox
extension, and working on a patch for Firefox 3.0.
I went to some of the after-hours activities for the GNOME Summit Boston. I'm going to PodCamp Boston this weekend.
I was writing my todo list management application in Django, but then decided to switch it to Pylons. Now I'm thinking I may just go a much easier route and implement it in web.py. A year ago, I wrote a wiki system that was code-friendly using web.py in three hours which included the amount of time it took to learn how web.py worked.
PyBlosxom work for version
2.0 has slowed considerably. I just haven't had much time to spend on
it. A bunch of us are hanging out in #pyblosxom on
irc.freenode.net and we're talking about things more often.
I met paulproteus in real life during the GNOME Summit Boston. I'm
trying to figure out how to create multi-page output using
docutils. There was some
development in that arena over the summer, some of it due to a
GSoC project. I need to spend some more time
to figure out what's available now in SVN, how to use it, and whether
it'll fix my problem.
I've upgraded all my machines to Gutsy. It's nice--the fonts seem to be much easier to read on both my laptop and my desktop with an LCD.
That about covers it. It's been a low-Python high-JavaScript month.
I've been doing Firefox extension development and it's been going pretty slowly because it's hard for me to figure out what's going on when things are running (and I'm not wildly familiar with the things I'm working with).
After whining about how I wish there was a REPL for JavaScript, I did a Google search and came across MozRepl. It's helping a lot so far. I'm not spending hours hunting for object documentation anymore.
On an interesting note, you connect to MozRepl with telnet and it has a line-mode interface. Turns out that Lyntin (a mud client I worked on years ago) works fantastically for this. I would assume most mud clients would because at heart they're line-mode telnet clients with a bunch of features designed to remove repetition in common tasks and make it easier to skim large amounts of output quickly without having to read through all of it.
For example, say I was interested in skimming changes for the
title attribute. I could do this:
#highlight {reverse,green} {title=*}
That will highlight lines with "title" in them from "title" onwards.
I'm hanging out on #pyblosxom on irc.freenode.net
more often now that I'm hanging out on irc.freenode.net
for work during the day. Zeth was on today and pointed out that if
you're running PyBlosxom with
Paste, then the default configuration
doesn't allow for css and image files to be served.
This weekend, I wrote a media serving plugin for PyBlosxom which solves
this issue, but I decided to spend some time to write a WSGI application
to do the same thing and use Paste's urlmap to handle
the routing. It took 10 minutes to throw together and it works nicely.
I'll clean it up and throw it in the Trac instance tomorrow. Over time,
I'm liking WSGI more and more.
I ordered a Seagate Barracuda Ultra ATA/100 drive from Amazon.com the other day and it arrived today. I opened it up to discover it's a PATA drive. However, I thought I ordered an ATA drive and not a PATA drive.... Long story short after an hour of researching and finally calling up a friend who does hardware work, I discovered that "they" renamed ATA to PATA so that it won't be confused with SATA. No one sent me the memo.
I was at Tag's Hardware in Porter Square (Cambridge, MA, USA) to buy Poly-acrylic for some shelves I'm putting up and they're selling decent bookshelves for $20.00. We bought one--it's pretty sturdy and it folds up for moving/storage/whatever. They probably have more left if you're in the area and interested.
I've been working through PyBlosxom stuff. I updated the web-site to use PyBlosxom 2.0-dev (in trunk). We worked through entry caching plans on the mailing list and implemented most of them. We've also been discussing and working through template variable syntax and semantics. I've been adding new unit tests and using tests to help work out the design issues. The testing framework has made it so much easier to do development work.
I've been writing a todo-list-tracking application in Django. I'm hitting a point where it's half-implemented, but I'm thinking I may switch back to Pylons because it's Paste-friendly and easier to deal with.
Bunch more stuff, but it'll be in separate entries.
I mentored Z who was working on pyblosxom-webfront which is a web-based interface to your PyBlosxom blog.
Overall I'm pretty happy with the project. I had a pretty crazy May and June that definitely affected the first half of the project, but Z and I had a few chats just before the second half and ironed most of the issues out.
While he was working on webfront, I rolled out PyBlosxom 1.4 (and 1.4.1 and 1.4.2) which have support for Paste. Paste makes writing plugins and testing them _so_ much easier. Z also worked out some problems with making complex plugins. We should look into refactoring the comments plugin accordingly.
From here Z says he'd like to continue working on webfront and maintaining it. There are a bunch of things that it's missing, but it's a good platform to build on and it was a good experience to work with him to get there.
Thank you Google!
I spent a large portion of the last few weeks at PCF building a migration script to migrate tickets from our Trac instance to bugs in our Bugzilla instance.
I started writing SQL scripts, but then it got too hairy because there are a bunch of Trac ticket fields that have no constraints and translating them to Bugzilla equivalents required mappings and temp tables ... I abandoned that approach pretty quickly and wrote the migration script in Python.
The outcome of the migration is pretty decent. We've spent time fixing the data in Bugzilla after the migration, but I don't think there's a way to do a perfect migration because of the nature of the two bug systems.
I thought the project was interesting and mentioned it to a few people. The most common thing people respond with when hearing I was working on migrating our bug data from Trac to Bugzilla is, "What??? WHY?!?!" and their eyes would open wide with shock. I think Bugzilla has an undeserved bad rap.
The scripts are here (participatoryculture.org) if anyone else with similar plans is looking for them.
As a side note, the Python Database API specification PEP is fantastic--anyone who contributed to it should get a gold star.
I'm really late to the PyPi party. Both of the projects I've worked on over the years are in PyPi, but neither are up to date and neither support easy_install.
Figured I'd update them now. Three things I bumped into while working on Lyntin:
That last one is kind of interesting. You can see the scores and the Cheesecake log output.
It's been a crazy few months... I worked like crazy the last two weeks of grad school, got my Masters, got married, went on a honey moon (or toffee moon depending on where you live), pushed out a new version of PyBlosxom, and ... got a job! I'll be a developer on the Democracy Player (soon to be Miro) at Participatory Culture.
I'm really psyched about this. Hopefully it nicely weds my Open Source/Free Software development hobbies with employment. Hopefully it nicely weds the way I like doing software development with the way I have to do it for work. Regardless, it's nice to be working in one major language (Python) rather than two (Java and Python). Also, there's a lot of really neat technology that PCF is using that I haven't worked with before--so it'll definitely be a growing experience.
I start next Monday (July 16th). Because I'll be doing Python development for employment, it'll be a lot easier to focus on Python-oriented things and blog more about Python the language, tools, methodologies and all that, too.
It's been 17 months or so since the last PyBlosxom release which for a small project is probably too long a period of time. Real life is a harsh mistress sometimes.
Changes:
w00t!
I went to the FSF GPL 3 release event and it was really interesting. There's been a lot of discussion and heated exchanges over the GPL 3, but I was in grad school and wasn't really paying much attention. Listening to the discussions at the event about GPL version 3 was really enlightening.
Personally, I'm excited about the license. It allays some fears I've always had as a developer. Going foward, I'll be putting the majority of my work under the GPL version 3 license.
I quietly released an RC2 for PyBlosxom 1.4 today after merging in Yury's
patch for Paste support and merging in Steven's work for WSGI support.
It's really awesome to be able to do paster serve blog.ini
and have things work. At a minimum, it'll be a lot easier to test
PyBlosxom--no mucking about with web-server configurations needed anymore.
We've finished moving all the documentation from docbook to reST format. It still needs a lot of work, but we're making measurable progress which is really cool. Also, the documentation is easier to work with and maybe that reduces the amount of energy it takes for people to help out.
PyBlosxom 1.4 should be released soon. Very soon. Will it be perfect? No, but it's a huge milestone for the project. That's pretty exciting in the grand scheme of things.
06/24/2007 - Fixed "server" to "serve". I keep typing paster
server ... which is wrong.
S and I decided to get a wedding photographer in addition to allowing our guests to take as many photos as they wanted of all aspects of our wedding (except when we were getting dressed [and ... undressed]). There were a few reasons for this one of which being the several horror stories we've heard about people's digital media dying causing them to lose all pictures of their wedding. Ick.
The problem is that there are a fajillion pictures and it's really hard to order them into a single consistent timeline. The wedding photographer we had1 had four cameras and took some 800 pictures. My dad took another 100 or so. Other people took a bunch, too. Right now I'm working with 1200+ pictures all of which are pretty big (between 5 MB and 10 MB each). It's not feasible to tweak them all by hand to order them. I didn't want to leave them unordered--my soul shudders at that thought. I needed a way to do batch processing to reorder pictures from a bunch of cameras into a nice timeline.
More after the break...
Blake poked me via email and suggested I put together some ideas for a PyBlosxom GSoC project under the PSF umbrella a couple of months ago. It was a hectic time, but I threw some ideas together based on items we had in the TODO list (many of which are pretty stale at this point). I'm happy to say that we had a great proposal for building a web front end for PyBlosxom--a tool that I think a good portion of PyBlosxom users would be happy to have.
I'll be mentoring this project over the course of the summer. Z has already started working on things and I think this will turn out nicely.
As a side note, this is a huge motivator towards finishing up a release and getting out a new version of the PyBlosxom manual. On the flip side, I'm getting married in a week so I'm finding it difficult to allocate time to get the work done. Wedding planning is intense. They should use wedding planning to teach project management courses--talk about shifting requirements and general project insanity. ;)
Someone posted my article Cleaning Up PyBlosxom Using Cheesecake onto programming.reddit which was a bit of a surprise to me.
I'll keep track of the entry and the comments that it generates in case there's any feedback that would be useful for making the article better.
I figured I'd post this because I just spent 24 hours trying to work out the issues.
I'm in a compilers class that's using the Modern Compiler Implementation in ML book (aka the Tiger book) by Andrew Appel. Over the course of the first 12 chapters, you build a compiler for a language called Tiger. Appel has a runtime.c that you can download from his web-site, but if you add functions to the runtime.c (for example, we added a ternary string comparison function which made string relops trivial to implement), then you need to compile runtime.c into assembler that's SPIM-appropriate.
Long story short I've got a Gateway 450 something or other laptop (i686) running Ubuntu Feisty Fawn and gcc version 4.1.2. I used the crosstool scripts from Dan Kegel. I used the demo-mips.sh script, but modified it to this:
#!/bin/sh set -ex # Big-endian MIPS TARBALLS_DIR=$HOME/downloads RESULT_TOP=$HOME/mipsgcc export TARBALLS_DIR RESULT_TOP GCC_LANGUAGES="c" export GCC_LANGUAGES # Really, you should do the mkdir before running this, # and chown /opt/crosstool to yourself so you don't need to run as root. mkdir -p $RESULT_TOP # Build the toolchain. Takes a couple hours and a couple gigabytes. eval `cat mips.dat gcc-3.4.5-glibc-2.3.5.dat` sh all.sh --notest echo Done.
Ubuntu has /bin/sh point to dash--but this causes problems when compiling glibc (see here). So I fixed /bin/sh to point to bash instead of dash. That fixes the "error: missing terminating " character" error.
After you get your cross-compiler working, you can compile your runtime.c into a runtime.s with something like this:
% mips-unknown-linux-gnu-gcc -S -mrnames -mmips-as runtime.c -o runtime.s.raw
After that, you have to remove a few things so that it works in SPIM. Olin Shivers has a page that talks about this some more.
Hopefully I included enough words in here that this pops up in Google and helps future compiler-class takers in the same position I was in.
I've been looking around for implementations of XML Schema and XPath 2.0 so that I can test some things out for a research project I'm working on. Essentially I need to be able to specify a schema in XSD, create an XML document (or two or three) that conform to that schema and then I need to be able to run a series of XPath 2.0 expressions on those XML documents. An implementation that works in Java or Python is cool, but at this point I'd even be willing to learn a new language to get something working.
In Java-land, the only XPath 2.0 implementation I can find is SAXON. However, the "free" version, SAXON-B, isn't "schema-aware" (i.e. it doesn't have XML Schema handling in it). The site says I can get an evaluation license... but I'm not really interested in evaluating SAXON--I just want to run some tests to make sure my paper is accurate.
JAXB has an implementation of XML Schema. JAXP 1.3 is in Java 1.5, JAXP 1.4 is in Java 1.6. Both JAXP 1.3 and 1.4 have an implementation of XPath 1.0, but not 2.0 (which makes sense given that XPath 2.0 is pretty recent).
Jaxen supports XPath 1.0, but not XPath 2.0.
I can't find anything else in Java-land.
In Python-land, there's 4suite which has XPath 1.0 support, but doesn't seem to know anything about XML Schema.
There's lxml which is a binding for libxml2 which has support XML Schema (at least, it has support for XML Schema datatypes), but doesn't have an XPath 2.0 implementation.
There's also Amara, but given the documentation talks about "node sets", I suspect it only implements XPath 1.0. That's all I could find in Python-land.
My research is probably spotty. I'm relying upon Google searches and what I can garner from 20 minutes of skimming the project web-sites. I've also been using some loose heuristics to disambiguificate1 usages of "XPath" with no version number--when someone refers to "XPath" or mentions "node-sets", I assume they're probably talking about XPath 1.0.
Anyhow, any ideas on XPath 2.0 implementations that I missed?
[1] - This is a word we used at ByAllAccounts often because it was amusing. There are other variations, too, such as disambiguificationalize. This sort of word bastardization makes documentation more interesting.
I saw Titus' Strangling your code and growing your test harness: ... entry and that's the process we've been using for adding a test system to PyBlosxom. We're still on step 2 or 3, though. We have unit tests for a portion of the tools module in and working but that's it. We need a setup/teardown code for testing a request on a basic blog for n variations of "basic blog". Getting there....
A few days ago, I saw on Grig's blog that Titus created a mailing list covering Testing in Python. I joined the list and it's been very educational. So far the posts have been in the "Hi--my name is _____________ (name) and I use ______________ (framework) and ___________ (framework) and ____________ (explanation for which framework gets used for which specific purposes)." Then this spawns a conversation with thoughts and insights and lots of applause. There have also been questions regarding how to use some of the frameworks and which framework would suit some need the best.
While I'm following the mailing list, I'm taking notes so that I can finish up this round of adding testing to PyBlosxom so that I can do a release this week. We're using nose and I'm using a similar structure that Cheesecake uses since I have some familiarity with their project.
It's a neat list so far. I'm glad Titus put it together--it's definitely solving my immediate needs.
I installed Mudos on my laptop which is running Ubuntu Edgy. I had two problems compiling the source for v22.2b14.
The first issue is this error when running make:
make: *** No rule to make target `obj/malloc.o', needed by `driver'. Stop.
The solution, bizarrely, is to just run make again. I
don't know what the issue is, but discovered this in the depths of the
mailing list archives.
The second issue I get when compiling is this error:
socket_efuns.c: In function 'get_socket_addres': socket_efuns.c:1198: error: invalid lvalue in unary '&' make: *** [obj/socket_efuns.o] Error 1
Doing this change fixes the issue:
$ diff socket_efuns.c.orig socket_efuns.c 1198c1198,1199 < addr_in = &(local ? lpc_socks[fd].l_addr : lpc_socks[fd].r_addr); --- > // addr_in = &(local ? lpc_socks[fd].l_addr : lpc_socks[fd].r_addr); > addr_in = local ? &lpc_socks[fd].l_addr : &lpc_socks[fd].r_addr;
After that, everything works wonderfully.
My semester break is drawing short and I didn't get much of what I wanted to get done done. I merged Lance's documentation fixes in, I'm fiddling with a new pyblcmd script, and I'm cleaning up things I started, but never finished.
Ryan is going hog-wild with getting the comments plugin to a better place.
I was thinking of switching the web-site to use MediaWiki and in doing so solve a bunch of issues we have, but I think I'm going to wait on that for a while. In the meantime, I do plan on doing a web-site update and make it look more like some other Python-project web-sites. In the process of doing that, I think I may move it over to be statically rendered.
That's it for this status report--trying to keep it short and sweet while getting across that some things are happening, but it's slow going.
Many thanks to Lance and Ryan and all the other folks who have been putting time and energy into PyBlosxom over the last few months. You guys rock!
I'm having problems with spam in my Trac instance which keeps track of my PyBlosxom plugins. It's ... irritating. Anyhow, now that classes are almost over, I decided to poke around and figure out how to delete them rather than mark them as "invalid". Turns out it's really easy:
trac-admin [project-dir] ticket remove [ticket-number]
I got a few comments from people who were interested in how I used Cheesecake to clean up PyBlosxom. I tossed around making it a series of blog entries but then decided to write it up as a technical article: Cleaning Up PyBlosxom Using Cheesecake.
I think it came out nicely, though parts of it are too "wordy". I really liked writing the article using Trac's wiki system. My only problem with Trac's wiki system is that the documentation for writing wiki macros needs a lot of help.
I'm going to update some of the PyBlosxom plugin writing tutorials I wrote a couple of years ago and put them in my trac instance, too. I still have work to do with PyBlosxom, but it's coming along very nicely. I'm working on unit tests and functional tests now.
I've been following Cheesecake development with the hope that it'd be a tool that would help me fix PyBlosxom's shortcomings, make it easier for people to use, and make it easier for people to develop. It has certainly been all that and more.
I've been going through the various kwalitee measures that Cheesecake does to understand them and I've been making adjustments to PyBlosxom's source code and project infrastructure. I've made a lot of changes so far, discovered some latent bugs and code problems, documented undocumented code, fixed existing documentation, and started writing tests.
It's a huge effort, but it's a lot easier with tools like Cheesecake, nose, pylint, and coverage. Additionally, the blog entries at AgileTesting and articles at Living in an Ivory Basement have been helpful. Also, I've been shamelessly copying the infrastructure of the Cheesecake project. That's made it a lot easier to get my head around various bits.
At the moment, everything is local. I'd start checking things in but SVN at SF is really flakey (though the SF site status page doesn't mention any SVN issues).
I see the next version of PyBlosxom having some bug fixes and new features, but generally it's going to be a release focusing on cleaning up the codebase and the infrastructure.
Out of curiosity, while I'm in the process of cleaning up the codebase is it interesting to anyone for me to write up more detailed blog entries covering up how and what I'm doing? It might help by giving outlining a gameplan for cleaning up other Python-based projects. If that's something you're interested in, toss a comment on the blog or email me at willg at bluesock dot org.
I just discovered the Python Sidebar and I'm not sure how I got along without it.
I finally released the contributed plugins pack for PyBlosxom 1.3. To be honest, I really wanted to get around to testing everything more, but it's a big project and I never made the time to do it. Rather than sitting on it forever, I decided to release it now. It's vaguely possible that someone out there will download it, discover that the plugins they're interested in are terribly tested, and help fixing the real problem which is that the only testing we do on the PyBlosxom project is anecdotal testing ("well, it works for me...") by setting up some kind of magical testing framework.
More details on the PyBlosxom site.
I found this article amusing.
Signs you're a crappy programmer (and don't know it) (Damien Katz)
On a slightly similar but different note, I'm working on upgrading a massive codebase from Java 1.3 to Java 1.5. Painful. Very painful.
I applied a few patches that I've received over the last month or so. I'll hopefully release the contributed plugins pack--there have been a lot of updates since I last released it (ages and ages ago).
Next step is to fold some more documentation into the manual and figure out to handle contributed plugins better. Need to figure out how to fix the problem that the ones I don't use on my blog are of unknown quality and different versions of the different plugins work with different version of PyBlosxom. I'd also like to re-organize the plugins into categories that make more sense.
At one point I was planning on building a page on the web-site tracking things that need to be done for PyBlosxom. Now I think I'll just put the list in a TODO.txt file in Subversion along with everything else. It occurs to me we probably had one at one point, but I probably deleted it.
Mark Edgar's PuTTYcyg patch is awesome. I've always had difficulties with the Cygwin console and using PuTTYcyg makes me a happy man. Definitely worth looking at if the Cygwin console issues (resize issues, fonts, copy/paste issues, ...) make life irritating.
I'm building a wedding site that contains mostly static material but has some material that's reminsicent of CMS and some material that's database-driven, too.
I surveyed the scene of Python web-frameworks and settled on Pylons for various reasons but mostly because:
I've spent 40 minutes or so fiddling with the site so far with only a
few minor issues which required me to go poking through documentation.
One of the issues is that I have a series of templates in my templates/
dir and I uncommented out the commented out code in the
template.py controller so it's like this:
from weddingwww.lib.base import *
class TemplateController(BaseController):
def view(self, url):
from pkg_resources import resource_exists
if resource_exists('weddingwww', url+'.myt'):
m.subexec(url+'.myt')
else:
m.abort(404, "File not found '%s'" % url)
That doesn't seem to work as I'd expect. For example, if I go to
http://localhost:5000/meeting, the url parameter
ends up as meeting but the resources_exist returns a false
even though there's a meeting.myt file in my templates
directory.
After fiddling with this and trying to figure out where pkg_resources is defined, I just commented the code out and changed it to this:
from weddingwww.lib.base import *
class TemplateController(BaseController):
def view(self, url):
m.subexec(url+'.myt')
which obviously does the wrong thing if the file doesn't exist.
Meetings that are done in a text-based chat interface (IRC, IM, talk, ...) are only as fast as the slowest typer.
SourceForge 1 now has Subversion access to project stuff so I migrated the CVS repository of all PyBlosxom things over to Subversion. Then I tested it out to make sure it works. So far it seems much easier to deal with in the grand scheme of things. I'll probably write more when I find something to kvetch about. :)
[1] For some reason, I keep typing "SourceForget"--not sure why.
Bunch of bug-fixes for things I didn't catch the first time around.
Changes:
It's a good release. Many thanks to Norbert (current Debian packager), Joey, Joerg, and the many people who upgraded to PyBlosxom 1.3 despite the fact we have no regression or unit testing system [1]--they are brave people.
[1] - This is a bad thing--we should fix this.
I admit that "solid bug report" is vague and probably different depending on the nature of the bug being reported. However, the amount of time it takes to research and fix a bug that has a well-written bug report vs. the time it takes to research and fix a bug that has a craptastic bug report is orders of magnitude in difference. In some cases, the latter bug report doesn't shed any light on the issue at all and thus won't result in a fix in any amount of time.
Anyhow, many many many thanks to Joey Hess to submitted a bug report in the Debian bug system (passed on to me by Norbert) regarding a problem with static rendering. He provided a wealth of information including his whole setup via subversion. He gets ten gold stars.
On a side note while I'm kvetching, I dislike bug reports that include a patch but don't specify what the problem is and why the patch is a good fix for the problem. It seems silly... you'd think I could look at the patch and work backwards to figure out what the issue is, but that is rarely the case. Often people who are providing the patches don't really understand what's going on at that point in the code and they've created a patch that "makes the problem go away for them" which is really different than "fixes the problem".
Norbert took over Debian packaging and has sent me a plethora of fixes, questions, and errata most of which I've applied, replied to, or at least thought about. Martin has also sent in several issues that will be fixed for PyBlosxom 1.3.1. Additionally, I went through all the bug reports on the SourceForge bugtracker and dealt with them.
In the process of doing all that, there were a bunch of bugs with 1.3 that got fixed. I also fixed Joey's problem regarding num_entries behavior. I'm re-thinking how some of PyBlosxom works (or doesn't work) and I've gotten all excited about making some changes.
I've done another huge push on the manual fixing a bunch of minor issues and folding documentation that existed in other places into the manual in the proper places. The manual is in docbook format and when I compile it (or whatever the verb should be) into a PDF, it clocks in at 76 pages. It's definitely the longest manual I've ever written. As time goes on, it gets more and more comprehensive. I hope people use it if only because I've spent days writing, honing, editing, and cursing it.
Next week some time (time-willing), I'll do another pass at overhauling the web-site and fixing the massive problem with plugins that we have. The issue is that I don't want to be doing contributed plugin packs--it's a pain in the ass and none of them are tested except the ones I use. On top of that, over the years people stop hosting their plugins which has caused some of the entries in the registry to become obsolete. I'm going to switch how I do things, ditch the registry plugin, and change the system so that the site hosts all the plugins that are offered. I'm also going to enforce some rules regarding things plugins need to have in order to be added to the registry.
Many apologies for the length of time that this has taken me to complete.
Changes:
Plugins that work for PyBlosxom 1.2 should continue to work with 1.3.
Overall, I'm pretty happy with it. It's not everything I originally set out to do, but it's a good amount of work for a release. Many many thanks to everyone who helped out.
You can download it from the PyBlosxom website.
I've already done a blog entry on ReleaseForge, but I just used it again and it's really fantastic. I sure makes releasing things on SourceForge _so_ much easier to do--I highly recommend it.
I'm releasing PyBlosxom 1.3 release candidate 1. w00t! A lot of work has gone into this and it's taken way way way too long to finally get it out. My apologies to everyone who's been waiting and such.
Changes between 1.2 and 1.3
Pertinent to users:
We added a "blog_rights" property. This holds a textual description of the rights you give to others who read your blog. Leaving this blank or not filling it in will affect the RSS 2.0 and ATOM 1.0 feeds.
If you set "flavourdir" in your config.py file, you have to put your flavour files in that directory tree. If you don't set "flavourdir", then PyBlosxom expects to find your flavour files in your "datadir".
The flavour overhaul is backwards compatible with previous PyBlosxom versions. So if you want to upgrade your blog, but don't want to move your flavour files to a new directory, DON'T set your "flavourdir" property.
Moved the content that was in README to CHANGELOG.
You can now organize the directory hierarchy of your blog by date. For example, you could create a category for each year and put posts for that year in that year (2003, 2004, 2005, ...). Previously URLs requesting "2003", "2004", ... would get parsed as dates and would pull blog entries by mtime and not by category.
Logging works now. The following configuration properties are useful for determining whether events in PyBlosxom are logged and what will get logged:
It's likely you'll want to set log_file and log_level and that's it. Omit log_file and logging will fall back to stderr which usually gets logged to your web-server's error log.
Pertinent to developers and plugin developers:
Nothing that I know of. Everything should work pretty much the same.
Download, comments, et al
Download it at http://www.bluesock.org/~willg/download/.
It's been locally tested (my blog has been running the version in CVS for over a month now), but not globally tested. While I'm pretty confident that it should be ok for most people, I'm sure there are some issues that have fallen through the cracks of our total lack of regression testing and unit testing environment.
As such, I heartily encourage anyone still using PyBlosxom to set it up locally and run it through the steps that your blog entails and let me know this week whether there are any issues.
If I don't hear from anyone by Saturday, I'll just release it at my leisure.
The future
This is it for me. This release fixes a bunch of flavour issues that needed fixing. It also includes a much better version of the manual and some work has gone into making it more Python-standards compliant.
Over the last 9 months, the world of web-application development and Python web-application development has changed radically. I'm a little tempted to re-write PyBlosxom using Paste, but I don't think it really helps our "typical user" much and I'm not sure it makes sense given that there are a variety of other weblog applications out there that are well-established and have more momentum.
As such, I'll be helping with minor bug fixes and that's it.
Happy new year!
My blog has been going up and down a lot over the last few days as I'm getting the kinks out of some code I re-wrote in PyBlosxom and searching for other issues. I've successfully transitioned to the new included RSS 2.0 feed without disturbing any of the planets that I'm on. Things are looking good so far. Release soon!
I re-wrote blosxom_path_info_handler and cleaned it up a lot. The adjustments also allow people to create categories that look like dates (and previously would get interpreted as dates and screw things up).
I'm going through the documentation, the bug list, and a couple of other changes I want to make. I'll also tackle any low-hanging fruit that's on my todo list. Otherwise, I consider PyBlosxom 1.3 pretty complete. If all goes as I plan, it'll be out before Christmas in some form.
I've been running my blog on the latest code and keeping track of all exceptions that get thrown and any other odd issues and things seem to be going well. As such, I'll be preparing to do a release candidate soon and then start the mildly painful process of re-writing the appropriate sections of the PyBlosxom manual.
I'm also taking some time to run Cheesecake against the codebase. The results so far are somewhat of a bummer:
[cheesecake:console] Detailed info available in log file /tmp/cheesecake_sandbox /pyblosxom-1.3.tar.gz.log [cheesecake:console] A given package can currently reach a MAXIMUM number of 560 points [cheesecake:console] Starting computation of Cheesecake index for package 'pyblosxom-1.3.tar.gz' index_unpack .................. 25 (package untar-ed successfully) index_unpack_dir .............. 15 (unpack directory is pyblosxom-1.3 as expected) index_install ................. 0 (could not install package in /tmp/cheesecake_sandbox/tmp_install_pyblosxom-1.3) index_file_announce ........... 0 (file not found) index_file_changelog .......... 10 (file found) index_file_ez_setup.py ........ 0 (file not found) index_file_faq ................ 0 (file not found) index_file_install ............ 10 (file found) index_file_license ............ 10 (file found) index_file_news ............... 0 (file not found) index_file_pkg-info ........... 10 (file found) index_file_readme ............. 15 (critical file found) index_file_setup.py ........... 15 (critical file found) index_file_thanks ............. 0 (file not found) index_file_todo ............... 0 (file not found) index_dir_demo ................ 0 (directory not found) index_dir_doc ................. 25 (critical directory found) index_dir_example ............. 0 (directory not found) index_dir_test ................ 0 (directory not found) index_docstrings .............. 70 (found 264/382=69.11% modules/classes/methods/functions with docstrings) index_pylint .................. 68 (average score is 6.77 out of 10) =================================== ABSOLUTE CHEESECAKE INDEX ..... 273 RELATIVE CHEESECAKE INDEX ..... 48 (273 out of a maximum of 560 points is 48%)
So, 273 out of 560... Could be worse, but should be a lot better.
The code seems to be working nicely so far. There's one piece I still want to code before a PyBlosxom 1.3 rc release. I still have to go through the manual, update the content, and do some more work on organization. It's likely I won't get to work on it until the end of the semester, so that puts the next release some time at the end of December.
I re-re-wrote the flavour template code for the upcoming PyBlosxom 1.3 release. It works like this now:
This allows you to put all your flavour files in a flavour directory that you specify in your config.py file.
This allows you to put all the flavour files in a taste.flav directory (for example, html.flav, happygoodness.flav, rss20.flav, atom10.flav, ...).This allows you to override individual template files from the default flavours. For example, if you wanted to add RSS enclosures, you can put a story.rss file in your $datadir/, $flavourdir/, $datadir/rss.flav/, or $flavourdir/rss.flav/ directory (depending on how you set things up) with the enclosure markup in it and PyBlosxom will pull the default rss templates and use your story.rss template.
This allows you to override individual template files depending on what category the user is looking at.
This makes it easier to package and distribute flavour packs because they can all sit in a single directory all by themselves.
There should be no backwards-compatibility issues with the new code between PyBlosxom 1.2 and 1.3.
NOTE: The code needs to bake a bit. I tested a lot of combinations of things, but I'm still finding occasional issues. This blog is using the latest code, so if you find any issues, write a comment below (assuming that's not broken) and I'll fix the issue.
I have one more big thing on my list of things to do for PyBlosxom 1.3. After that I'll probably release an RC1. Depending on school work, that could happen in the next few weeks. If you want to see the code now, get it from CVS (instructions for CVS access here).
I was talking with Josh the other day and he told me that I should take the time to learn Subversion and switch over rather than investing more time to tame my projects with CVS and CVSTrac. So I spent a good portion of today moving my PyBlosxom plugins (the ones that I wrote and/or maintain on my own) to a Subversion repository and Trac.
There are a couple of things that will take getting used to, but overall I've been able to replicate everything I did with CVS in Subversion.
I'm still making modifications to the setup, but I'll be hosting all my PyBlosxom plugins work at http://www.bluesock.org/~willg/cgi-bin/pybltrac.cgi/. I've allowed anonymous ticket creation for feature requests, bug reports, and the like. If you're sitting on issues, patches, and things of that nature, feel free to submit them.
I've been following (very loosely) Ian Bicking's (ianbicking.org) paste progress and it's really amazing stuff. Today, I bumped into his screencast on Ajaxy exception catching. That was really cool and I could see how it could be immensely helpful with debugging/fixing PyBlosxom plugins.
I'm adding "investigate porting PyBlosxom to paste" to my todo list for winter break; paste looks seriously awesome.
I'm going to release the PyBlosxom contributed plugins pack 1.2.3 for PyBlosxom 1.2 in the next couple of days. So if anyone is sitting on any fixes that need to go on, let me know soon.
This has a few fixes here and there--some of which are cosmetic. It also has a behavior fix for the comments plugin so that comments are shown if you have ?showcomments=yes in the querystring as well as when the specific story is viewed.
Prior to today, I was maintaining all my PyBlosxom plugins by hand... which was kind of stupid, but I hadn't really gotten around to investigating better solutions.
However, that day has come! I've pulled them all into a CVS repository and set up CVSTrac to manage documentation, bugs, features, and allow people to see version history for all of them. I'm in the process of going through all the plugins, adding CVS tags, updating copyright dates, fixing documentation, adding notes in regards to where the plugin is maintained and all that.
I aim to make the end result more organized for me and users looking for plugins and also require less effort to maintain.
I merged all the changes I've made in the PYBLOSXOM_1_2 branch back into HEAD. Now I'm in HEAD and I'm going to do PyBlosxom 1.3 work until I'm ready to release. At that point, I'll make another branch for PyBlosxom 1.3 fixes and such.
I've got the following items in my todo list for PyBlosxom 1.3:
Why make this PyBlosxom 1.3 and not another minor 1.2 revision? Well, it has to do with the adjustments needed to fix bug 1202107. PyBlosxom checks the content-type to see if it's xml and if it is, then it escapes the $title and $body variables which drives everyone trying to do an xhtml or other xml output crazy. The only ways to fix the issue is to do a hack on the hack or introduce a backwards-incompatible change. Given that I'm more interested in the latter, I figured it's better to bump the version so that it's clearer that the user will need to make some adjustments to their PyBlosxom configuration when they upgrade.
[1] $title_encoded, $body_encoded, rfc822 date, iso8601 date,
and possibly other stuff
[2] If you want to help with building flavours, let me know.
8/6/2005 - I added bug 1252678 to the list of bugs to be fixed in PyBlosxom 1.3.
I implemented Matt Weber's idea to show comments when bl_type = "file" instead of depending on a "showcomments=yes" in the querystring. I didn't remove the checking for "showcomments=yes", however--I figure having both covers all our bases. This fixes the ramifications of a poor decision on my part.
I made some changes to the debug renderer to make it easier to use. It now sorts the keys for mappings and prints the keys in blue. It's much easier to read now.
I submitted a bug report on the PyBlosxom package based on an email I got from Ted from Dave from Zack. I posted a security issue on the PyBlosxom web-site to notify users. I also forwarded the issue to the pyblosxom-users mailing list. Hopefully the news will filter down to all the people that need it.
I'm going to do some more PyBlosxom work over the next week. I want to merge some functionality in from plugins into the core. I first need to merge all the changes I've done on 1.2 back into main branch. Then I'll do the work in main and create a 1.3 branch when I release 1.3. If there are any features people are itching for, now's the time to let me know. Anything I don't plan on working on, I'll toss on a web-page on the web-site so everyone can see the wishlist and the status of where things are. It's interesting to note that the wishlist and a todo list are themselves in the wishlist and todo lists.
Wow! Martin wrote up a howto for installing PyBlosxom on Debian for multiple people.
There's a series of things here I don't really know about (e.g. what kinds of things should go in /srv?). At some point, I'd like to fix PyBlosxom so it's more "standard" in terms of installation and configuration for web applications.
Here's the link for configs/pyblosxom which walks through installing a single software installation on Debian for multiple people.
Joseph pointed out a problem where IE 6 won't display a cached page when it gets a 304 from the conditionalhttp plugin. (The issue is at the bottom of the email.)
I did some poking around and discovered on Wednesday that this happens on his blog as well as on my blog with IE 6 on Windows XP. On Thursday, I was no longer able to reproduce the problem on my site, but Joseph's was still broken. I don't know off hand what changed with my site, though I did do an apt-get update Wednesday night.
Anyhow, the 304 response from my site (which seems to work fine now) is (note the server line is wrapped):
HTTP/1.1 304 Not Modified
Date: Thu, 23 Jun 2005 14:32:26 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.4 \
PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d DAV/1.0.3
ETag: "1119536230.43"
Last-Modified: Thu, 23 Jun 2005 14:17:10 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
And from Joseph's site (which is still not working):
HTTP/1.1 304 Not Modified Date: Thu, 23 Jun 2005 14:37:15 GMT Server: Apache/2.0.46 (Red Hat) Connection: Keep-Alive Keep-Alive: timeout=5, max=100 ETag: "1118428239.0" Vary: Accept-Encoding,User-Agent =bunch of funky non-printable characters here=
Looking at responses from other requests to Joseph's server leads me to believe that pages are gzipped. I'm not sure if that's part of the issue or not.
My site: http://www.bluesock.org/~willg/blog/
Joseph's site: http://reagle.org/joseph/blog/
I'm running PyBlosxom 1.2.1 with the contributed plugins pack 1.2.2 with conditionalhttp. I think Joseph is as well. I have no idea if this is affecting anyone else--no one else has complained on the mailing lists or anywhere else that I've checked.
Anyone have any ideas as to what might be happening?
This is the third release of the contributed plugins pack for PyBlosxom 1.2.
Here's the list of changes between contributed pack 1.2.1 and 1.2.2:
GeneralThanks to Steven, David, Joseph, Matej, and Nathaniel for their contributions and help.
If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.
Find the contributed plugin pack here (contrib.1.2.2.tar.gz).
I discovered "Why I hate Advocacy" from jgoerzen.
I encounter this regularly when talking about operating systems, programming languages, text editors, and even non-technical things like car manufacturers, methods for making coffee, types of beer, music, politics, .... I never connected it with a "want to be part of the tribe" behavior. I wonder if this behavior is something that's relatively recent or dates back to primitive man. Regardless, it makes it difficult to discuss things in a rational, objective manner to understand what's really going on and the nuances involved.
Also on jgoerzen's blog entry is a link to "Why smart people defend bad ideas". Reading the two essays back to back was really funky.
This is a minor bugfix for PyBlosxom 1.2. If you use the conditionalhttp plugin, you'll want to upgrade. Otherwise, it's not crucial.
Changes:
Doug was going to do a unit testing or a regression testing or some kind of testing system in PyBlosxom so that we'd have testing and wouldn't have to do the manual testing and the "well, gee, it must work because I don't think I did anything wrong" [1] type testing. But then he ran out of time or interest or something. That time period of PyBlosxom development was a little rough for all of us.
Anyhow, I bumped into this blog entry on Functional testing in Paste which at first blush looks fantastically awesome for testing PyBlosxom stuff. It's based on testing applications with Paste (Paste).
I'm tossing this in the blog in case anyone is interested in working on fleshing this possibility out or in case I discover some free time with nothing to do.
[1] I'm a huge offender of this in regards to side projects.
06/01/2005: Added a necessary footnote.
I keep seeing articles and quotes where people in total ignorance state that Open Source is dying and then they turn and point at the number of dead projects on SourceForge to back up their ridiculous claims.
Quick note, I'm going to use the term "Open Source" in that silly loosey-goosey way many "journalists" in the media use it. Otherwise this mini-article looses its oomph while I do vocabulary translation.
There are a lot of dead projects on SourceForge and I think the number has nothing to do with the present and future of Open Source as a method of developing software or as a classification of software.
I'm going to try to fix a couple of issues before releasing PyBlosxom 1.2.1 and contributed plugins pack 1.2.2. The issues are as follows:
I'm working on PyBlosxom Manual changes as well. I think it's good to add a chapter on comments and I need to flesh out the chapter on syndication, too. If anyone wants to help with the PyBlosxom Manual, let me know--I'm happy to pass off some of the writing/collection/verification work to other people.
If you find any problems with PyBlosxom 1.2 or the contributed plugins pack--let me know those issues as well.
The last couple of weeks have been really crazy. S went off to New Jersey for the weekend, so I've had a few days to work through the things in the bottomless queue of things to do. I've been making a lot of progress, but the queue is still daunting.
There were a few bugs found in the contributed plugins pack 1.2.1, so I'm going through, fixing the ones mentioned on the mailing lists and fixing some additional issues as well. I think I'll be done with the things by Monday.
In tracking down problems with conditionalhttp, I found a bug in the PyBlosxom blosxom renderer. I think it only affects conditionalhttp, but it does so in a way that makes conditionalhttp totally useless. If conditionalhttp looks at the If-Modified stuff and decides that the content has not been modified, it issues an HTTP 304... but then the renderer goes and renders all the content and sends it down the stream just as it would with an HTTP 200. Needless to say, this doesn't do much to curb bandwidth usage.
I'm hoping to fix the problem where we fetch and filestat all the blog entries multiple times in a given PyBlosxom request. It won't be the amazingly elegant fix I was hoping to do a couple of months ago--but that requires a whole lot more work and rewriting a bunch of things in a non-backwards-compatible way and thus disrupting plugins and such.
That brings me to the PyBlosxom manual work I'm doing. The manual is already 46 pages long (that include the GDFL text). I haven't covered developer topics yet--mostly I've spent my time writing and re-writing content dealing with installation, setup, configuration, flavours, plugins, static rendering, and writing entries. I'm still getting my feet wet with docbook, so that's causing it to take longer.
Manuals take a stupendous amount of time to write. Anyone who tells you otherwise is an armchair developer.
Incidentally, if you've even looked at the manual, let me know. I have no way of knowing whether I'm doing a lot of work for nothing. I'm also very interested with problems people have, portions that are vague, and any other comments. Additionally, if you want to help out, let me know.
This is the second release of the contributed plugins pack for PyBlosxom 1.2. In terms of functionality, there were a bunch of fixes to the comments and trackbacks components and I overhauled pycategories. Beyond that, there were a lot of license changes (or in most cases license applications) and some documentation changes. In general, this release is a huge milestone for sorting out the big mess that was the contributed plugins.
Bravo to Wari, Ted, Steven, Blake, Bill, and everyone else that was involved in pulling this together.
If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.
Find the contributed plugin pack here (contrib.1.2.1.tar.gz).
I've been doing SourceForge releases for years and it's kind of a pain in the ass and I've always dreaded the two or three hours it takes to get all the pieces in line and do a release.
Steven Armstrong mentioned using ReleaseForge which makes half of that process _so_ much easier to deal with. I highly recommend it to anyone in the same boat I'm in.
The nice thing about writing the logic backwards for something is the behavior ends up exactly the opposite of what you were expecting. [1] That's what makes this sort of thing easy to find.
After you realize what's going on, it becomes a matter of figuring out where to place the ! .
[1] That's a terrible sentence.
I plain ran out of time and energy to work on PyBlosxom, so I stepped down as maintainer. I'll stay on the project as an occasional developer.
I went through my plugins and discovered wbgpager had a bug in it that prevented it from working with PyBlosxom 1.2. So I fixed it and released wbgpager 1.2. You can find it here with all the other plugins I've done. I also made some fixes to some of the other plugins. So if you're using anything I wrote, you might want to check to see if there are new versions.
Seems like it's ok so far. So I released it rather than continuing to sit on it. I've done a lot of work on the manual to cover the areas that were covered poorly or not covered at all. There's still a lot of material to cover, but we're definitely making measurable progress in that direction.
Steven Armstrong did a lot of work to get mod_python, WSGI, and Twisted supported. I'm not sure why anyone would use WSGI or Twisted, though, since they don't appear to make much difference in how fast PyBlosxom works. mod_python definitely helps, though. Steven has some runtime statistics here.
This feels like a good release. We met some goals, we didn't sit on it forever, the documentation is an order of magnitude better than it was for the previous version (though it has a long way to go, still), and we fixed a bunch of bugs.
Having said that, it's definitely not necessary for people to upgrade. I think if your blog works and you don't need to futz with it to get additional functionality, leave well enough alone.
I'm almost done the next version of the PyBlosxom manual. At the suggestion of Steven, I converted the manual thus far from html to docbook. I still need to do a lot of work in terms of indexing and adding warnings and notes and various other indicators like that. I'm busy re-writing chapters to reflect issues people are having on the pyblosxom-users list.
I think I've worked between 20 and 30 hours on it over the last week and a half--it's almost like another part time job.
We're going to try to push out PyBlosxom 1.2 in the next week or two. Steven did a lot of work fixing up static rendering and also fixing the architecture pieces that caused PyBlosxom to kind of suck when used in various frameworks like WSGI, Twisted and mod_python. I'm also going to do another round of documentation content.
We're going to push fixing the file handling to the next version. We want to allow for index caching and also reduce the number of times PyBlosxom walks your blogdir for entries. Both of these new abilities will significantly reduce the time it takes for large blogs to render. Getting there....
The plan is to have these changes in before Ted's talk at PyCon.
Got the notice from Network Solutions today stating that unless I renew right this second, the domain name is free again for anyone's taking.
I had worked with George to get Planet PyBlosxom up and running, but he seems to have paged out and hasn't responded to the last few emails I've sent.
It was an interesting thing to run for a year.
In lieu of other solutions, I'm going to start releasing contributed plugins plugin packs. This one should work with PyBlosxom 1.1.
If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.
If this works out, then I'll continue releasing contributed plugin packs that match up to PyBlosxom.
Find the contributed plugin pack here (contrib.1.1.tar.gz).
02/23/2005: Changed the url. Decided to do an actual "release" and store it on the PyBlosxom site.
Steven's been doing development on PyBlosxom to allow for other frameworks than plain CGI. The architecture changes he's making solves some other issues as well. The problem we've bumped into is that one of the things he wants to do requires us to change the minimum Python version from 2.1 to 2.2.
Details here.
Bill noted that it's likely that PyBlosxom won't work in 2.1 as it is now anyhow. I'm not sure--I don't have Python 2.1 anymore.
So the question is would it be ok to change the minimum requirements. Some folks who cannot change the version of Python they have will have issues with this (obviously), but is it a good idea anyhow? Is the world at a place where it's common to require at least Python 2.2 a for projects?
A while back, I adjusted the comments plugin locally so that it would allow me to have plugins that change the template type they use from "story" to other things. A couple of months ago, I sent Ted an email with which pieces go in which templates. Figured I'd stick that here in case someone is looking for it.
This is only for the "story" section. The head template goes before and the foot template goes after this example. This also only works with the latest version of the comments plugin that has the template stomping code removed.
<div class="news"> <- story.html <h2>$title</h2> | <div class="content"> | ... | </div> | links | </div> <- <div class="comments"> <- comment-story.html <div class="comment"> <- comment.html Posted by $blah at $blah | $blah | </div> <- <div class="comment"> <- comment.html Posted by $blah at $blah | $blah | </div> <- <div class="commentform"> <- comment-form.html form stuff here. | </div> | </div> <-
I finally got around to releasing PyBlosxom 1.1. The big change is that I'm only planning to work on and maintain the core--I'm hoping someone will come along and pick up maintenance for all the contributed plugins. I haven't figured out what the contingency plan will be. I might maintain that too, but whine about it very loudly until someone gets tired of me whining. I'm also slowly getting through working on the documentation. I noticed that the wiki that I'm basing a portion of my documentation on disappears every now and then. So... I'm thinking that's a good sign that I should finish up quickly.
George called me up and offered to take Planet PyBlosxom off my hands. I want to pass off all the little things to other people in the PyBlosxom community so that:
In the meantime, I'm working on finishing reading Dive Into Python. It's one of those books I wished I had read years ago. I got a hard-copy from my parents for Christmas. I've put a halt on coding until I'm done.
I was checking my apache logs and noticed there are dozens of feed readers pulling my RSS data. They're not pulling index.xml--which is the RSS 2.0 nicely-rendered data, but rather the RSS 0.9.1 flavour that comes by default with PyBlosxom.
The problems with this are two-fold. First, I don't have num_entries set in config.py. So every time someone requests the RSS 0.9.1 feed, they get all of my entries. It's around 340K or so. I'm amazed no one ever complained about this. If they had, I would have told them to get the other feed--the one I advertise--instead.
The second problem is that I didn't have the conditionalhttp plugin running. So every time someone requested the RSS 0.9.1 feed, they get all my entries--even if I haven't added any new ones since the last time they requested it.
I couldn't adjust the num_entries property in my config.py file, though, because it would mess up my paging plugin. So I tossed things around a bit and decided to add this code to my config.py file:
import os
query_string = os.environ.get("QUERY_STRING", "")
if query_string.find("flav=rss") != -1:
py['num_entries'] = 20
This code checks to see if someone is grabbing the RSS flavour of my blog which is my unadvertised-I-wish-no-one-would-request-it RSS 0.9.1 feed and set the num_entries property to 20. Otherwise, it doesn't get set.
Then I tossed in the conditionalhttp plugin which does the whole last-modified thing further reducing the amount of bandwidth I'm burning away pointlessly.
Lyntin, one of the projects I spent many many hours on, is now listed in the FreeBSD ports system.
Update 12/20/2004: The FreeBSD ports work was done by Ste. Turns out this got Rob excited so much, he built an ebuild for Gentoo! More information in the comments.
I've got JDEE 2.3.4 and Apache Ant 1.5. The problem I was having was that I'd get this error message whenever I tried to do C-c C-v C-b (i.e. build my project using ant):
ant -buildfile 'c:/Tools/src/spiderutil/build.xml' -emacs Buildfile: 'c:\Tools\src\spiderutil\build.xml' does not exist! Build failed Compilation finished at Tue Dec 07 11:22:24
Anyhow, after some poking around, I discovered this post (http://article.gmane.org/gmane.emacs.jdee/3910/match=+buildfile+exist) which helped me fix my issue. I went into jde-ant.el and removed two instances of "delimiter" and now everything works super duper.
I was reading the Debian Weekly News (from 11/30/2004) and one of the blurbs mentioned putting DWN in RSS format and then also mentioned that Gmane already does this for all the mailing lists it tracks.
"Blog" versions of the pyblosxom mailing lists:
And it has RSS. RSS versions of the pyblosxom mailing lists:
That's amazing.... Talk about killer services.
I did a third attempt to get Eclipse working and I got it mostly working but it didn't jive with our codebase very well and it takes GOBS and GOBS of memory.
I decided NetBeans took up too much memory as well (200MB at various points depending on what I was doing) and I kept bumping into weird NullPointerExceptions in the IDE itself. If I had more time, I'd spend more time: a) fleshing them out, b) providing bug reports. But the issues were too sporadic and it was taking too much time to come up to speed to the point where I could use it all the time. And the VSS plugin was kind of flakey and made me nervous.
I uninstalled both NetBeans and Eclipse and installed Emacs. I stuck Viper mode at 2 and after reading documentation for a bit, I finally made some connections I didn't make the last time around with Emacs and I've been working with it most of today and part of yesterday without any issues.
Helpful Emacs links:
I gave Bill Mill CVS checkin permissions the other day. He's interested in working on the static rendering and the problems of storing metadata. The former (static rendering), I'm psyched to pass off to someone who will work on it and fix the various issues it has. At a bare minimum, I'm psyched to pass it off to someone who wants to think about it.
The latter (metadata) is something we need to figure out how to deal with and soonish. The pyblosxom-users and pyblosxom-devel mailing lists have had several people pop up with their own ideas about what constitutes metadata, where it should be stored, how it should be stored, and how to access it. But few, if any, of the proposals seem to be in-line with the PyBlosxom mission. Though maybe it's not clear what the mission is. That's a topic for another entry.
Bottom line is that I'm going to hold off on releasing pyblosxom 1.1 for a few days in case Bill wants to change things.
Bill Mill's weblog is here. He talks a bit about metadata in entries and del.icio.us-style keywords.
Also, SourceForge is finally getting around to updating their web-servers and are planning to install a version of Python greater than 1.5.2. When that happens, I'm going to re-do and move the PlanetPyBlosxom web-site. I'm hoping Wari will approve moving the PyBlosxom main site as well. If he does that, then I want to merge the two sites, fix our problems with documentation, and centralize everything under one big project web-site that's agnostic of the people involved. That's a bit project. It may be that I'll wait to do pyblosxom 1.1 release until after the "big move".
A while back, several people offered to help out but I severely lacked the resources to sort everything out to take that offer. I'm hoping to make development much easier for people who want to hop in, implement a feature they need, and hop back out again and also make room for growing PyBlosxom beyond its blosxom roots.
So that's the update. Any thoughts or comments, leave them below.
I think I've removed over 100 spam comments from my blog in the last 48 hours. I'm a little tired of it, so I added a few obvious words to my word blacklist and then I went and modified the comments plugin to allow for "draft" status.
Then I wrote a small script that goes through the directory, finds all the comments in draft status, prints each comment to the screen and asks me what I want to do with it. That'll prevent comments from getting published without my manual approval.
It's interesting to note that many/most of the comment spam are comments on my entries on comment spam. Amusing....
I finished taking the GRE so now I'm going to start the long process of moving everything in /contrib to the registry, moving the flavours to the registry, and then going through the steps to release PyBlosxom 1.1.
We'll do an RC and wait a week for people to speak up about issues. That puts a PyBlosxom 1.1 release around the end of October. Things that will be in the release:
We're also removing the contrib directory and all the flavour examples. This is probably going to be controversial, but I don't think we have enough polish to continue distributing them with PyBlosxom and it'll be easier to distribute fixes and such if they're separate from the PyBlosxom release.
It's getting to be a drag when the nicest comments I get from my blog are comment spam for a casino site. "Thanks for the great work!" "That entry was really helpful!" "It's really nice to have people like you around!"
If I were a less self-confident person, I'd filter out the actual spam part (usually the web address) and leave the rest of the comment be. I'm sure these spam folk mean everything they say.
I had a splendid weekend with S's parents and then bumping around Harvard Square on Sunday. I did some studying for the GRE, but mostly took a couple of days off from doing work.
I also finished up overhauling all the code on DarkRifts to work with the MudOS v.22.2b14 driver. There's a huge amount of code and there were a lot of problems most of which are sorted out now. There are still a few problems, but no one seems to be logging in, so I don't really feel any urgency to work through the last bits.
I'm planning on pushing pyblosxom through to a 1.1 release soon. First, I'm going to package up the flavour files into flavour packs for the registry. Second, I'm going to add documentation to all the contributed plugins and move them all to the registry. Accomplishing those two tasks should give the code in CVS enough time to bake. Then we'll do a 1.1 release and start thinking about 1.2 which will likely involve a minor overhaul to how we pull files from the file system.
The next two weeks will be pretty busy. Already I'm way behind in replying to email.
I'm going to spruce up the comments plugin that comes with PyBlosxom. I'm going to merge the changes I've made locally with the contributed version:
I may incorporate the changes that Jesus did or at least figure out how to make that a plugin kind of thing.
Also, there should be a way to kick back messages to the user who just did stuff with the comment form. Then we can kick back messages when comments are rejected and accepted for better usability.
09-27-2004: Updated "John" to "Jesus"--I totally got his name wrong. Oops.
:g/^$/d
From tip 372. I keep forgetting how to do this so I'm writing it down.
Brett discovered some issues with booklist as it interacts with comments. So this fixes those issues.
You should note that if you're using booklist and comments, you should have at least 2 books in your list. Otherwise comments sees it as a single entry, decides to show comments for it, and then stomps on the property in the entry that dictates which template to use. That's a bug in comments that needs to get fixed.
Get it on my pyblosxom plugins listing
Fixed encoding issues and some other things. Thanks Aslak!
Get it on my pyblosxom plugins listing
I've got one of those GRE study guide prep book things and they have a wordlist of 3500 words that I should know. The breakdown is something like this:
That leaves 30% of the words to learn. Course, that's like 1000 words so I decided to put all the ones I didn't know in a wordlist file and wrote a quick application to pull up a random word from a random wordlist (the 3500 words are broken down into 50 or so wordlists) and give me the word and definition. I figure I'll start using them in emails and other digital correspondence and that way I'll cycle them into my vocabulary.
Feel free to join along in this little game of mine. It's a game I like to call, "I don't want to be studying--I want to be programming".
There are a few people doing analysis on the tools.Walk chain with the hope of slimming it down because it's one of the corner issues with PyBlosxom scaling up to thousands of entries. I don't really have time today to look at them (I'm at work right now), but I will (hopefully) soon and hopefully this spawns a discussion that results in better PyBlosxom code.
There's been a flurry of email on the PyBlosxom mailing lists over the last month. I'm totally buried at the moment, so I haven't had time to go through them and figure out what it all means in the grand scheme of things.
I updated the todo list with everything in my head right now (though I'm sure there's other things floating around that aren't on that page).
Robert Wall is working on doing analysis on PyBlosxom and coming up with some code to fix issues he's uncovering.
Hopefully, his work and the work of others will result in some big fixes to PyBlosxom that will (hopefully) simplify the architecture, reduce the number of performance issues, and open up more possibilities.
I also finished up work on Planet PyBlosxom which I had been threatening to do for a while now.
Lots of progress, though. I wish I had more free time to help grease the skids a bit.
It's really neat to watch skilled project managers step up to the podium and in a few paragraphs walk through what's happened, what the options are, why he/she is choosing a specific option, and then examine the process through which they arrived at that option and suggest ways of fixing the process itself. I've always loved to work for project managers that are highly aware of the immediate problems as well as the processes and machinery we're using to solve those problems and can actively tweak both.
Anyhow, Guido has written up his thoughts on the J2 proposal and seems like they're sticking with the <at> proposal. I honestly don't even know what decorators do--so I don't really know enough to care one way or another. I really hope some day soon I get some time to Dive into Python and catch up on some of the language features I'm really missing out on. It'd help my projects out a _bunch_.
Fixed a bug where categories with four letter names were getting picked up even if the name wasn't all digits. Thanks Ludvig Omholt!
Pick up the new plugin here: my pyblosxom plugins.
David Ascher started using PyBlosxom and there are a couple of other users who look like they're just starting to use it as well. I think that's fantastic--especially given that the project is on life support right now.
Life support? What makes me say that? Well, I've been threatening to do a 1.0.1 release for months but never did it. Development has all but stopped because there aren't any active developers. Back when I released 1.0, I told people I wasn't going to touch it for 6 months because I was really burned out on this project and I had too many other things going on. So then nothing happened except a mild trickle on the mailing lists.
I'm not sure what to do. I can't really take on another project and push it through the motions. PyBlosxom has documentation, but it's mediocre and has large gaps and it's spread across two sites one of which I don't think most people get to. The debian maintainer for the PyBlosxom package needs help updating the package, but I don't know enough about packages to help and haven't had the time to work on it. There has been some interest in a flavour registry, but it seems that there's only interest from a "we want a flavour registry" perspective and very very little to no interest from a "I'd like to contribute to a flavour registry" perspective. Blah blah blah.
There are a bunch of issues and no one to solve them. I'm really hesitant to throw my energy at this project again. Part of me wonders if I should just start solving some of the smaller problems that need to get solved (lack of testing infrastructure, lack of centralized documentation, ...) and then go from ther step by step. Seems so overwhelming.
Not to mention that my life is a mess right now--I'm still moving and I've got a list of promises I haven't fulfilled dating back to two or three years ago. Then I got bitched out on one of the projects I work on for being an elitist egomaniac. I just want to help identify and fix problems to make things better/easier/faster/more useful! Is that so wrong? I'm just one man! Gah!
I got a comment from David Ascher on this entry which pointed out some issues with the wbgamazon plugin. After a few minutes, I fixed the problems listed and released a new version.
I've blogged for so many months now that the Archives listing on the side was getting pretty long. I don't really want a long list of months and years there, so I was looking for options.
Ned Batchelder lists his archives by year. For each year, there's a summary page by month which lists the dates and titles of all blog entries for that month. I really liked this idea, so I wrote my own archives plugin to use it. It's not exactly the same--the output is slightly different. It's good enough for me, though.
Had to look this up for a friend. The "text-align" css property allows you to align the value inside a form input text box.
<input type=text style="text-align:center" name="blah" value="blah">
I keep forgetting this and forgetting where I wrote it down. Irritating.
<meta http-equiv="refresh" content="0; URL=http://bluesock.org/~willg/blog/">
Turns out it was creating garbled yucky stuff that hosed my RSS 0.91 feed. I fixed it so that if it thinks it's outputting to an RSS feed, it just returns rather than doing the transformation.
I should look into making this a postformatter--that would be better.
Ahhh--just got hit with my first comment-spam experience. That kind of sucked but was pretty easy to deal with since Ted organized comments as separate files.
If it happens again, I'll have to think about how to deal with it. Maybe switch to a comment approval process or something.
I got a bunch of really helpful responses from my previous entry and I'm pretty sure that my problems were two-fold: my code was missing some stuff (the code I posted and what I actually had were different--go figure) and my testing program had a bug (or two or three).
Anyhow, my knowledge of file locking on Linux (and possibly other Unixs) is pretty abundant now (or so I think). This helped to fix a problem I had at work as well (not the file locking part, but the thing I needed file locking for helped me at work).
Python has the fcntl module which has a flock and
lockf. I'm not entirely sure what the difference is, but
there are man pages on both functions as the Python versions call their
C counter-parts.
There's a good article on file locking that might be located at /usr/src/linux/Documentation/mandatory.txt (though it wasn't on my system--a Google search helped me out) that's pretty interesting. Also, there's explanations of file locking between processes and the issues involved in Advanced Programming in the Unix Environment and Linux Application Development.
My specific issue was with Exim and PINE. Both have documentation as to how they lock mbox files before playing with them--things a Google search reveals without much effort.
Anyhow, I'm pretty sure my code works now. I'll do some more sophisticated testing this weekend to make sure everything is kosher.
Thanks to Chris, Jason, John and Lance for their help.
![]() |
Linux Application Development |
![]() |
Advanced Programming in the Unix Environment |
I wrote my own web-mail client (bluemail) because I wanted a web-mail client that would work along-side PINE and figured I'd just roll my own in Python. I work on it from time to time--mostly when someone requests new features. Right now I'm trying to implement deleting of items in a given folder.
The problem I'm having is a file locking issue. When the user clicks on the INBOX link, it opens up their inbox file (an mbox file in /var/spool/mail/) as the user. That works super. I parse out the mbox and display a bunch of email one-liners. The problem comes in that I can't seem to open the file as r+, lock it, parse it into email, change some of the email (whether by deleting the email from the mbox file or changing the attributes of the email [i.e. marking the email as having been answered]), then write the changed file back to disk without the possibility of having another process (our MTA, for example) slipping in and changing the file beneath me.
Right now, I open the file like this:
import fcntl
f = open("/some/file", "r+")
fcntl.flock(f, fcntl.LOCK_EX)
That should work fine (as far as my research has told me). I did notice some places that say that LOCK_EX only works when you open the file in "a" or "w" mode, but I've got it opened as "r+" which means I'm going to update it later, so I'm puzzled.
Anyhow, using the code above doesn't seem to lock the file. I can run the above code thereby "locking" the file and then in another process open the file, read the file, and write to it. That indicates to me that it's not really locked.
Any ideas how I can resolve this? I need to be able to open a file for reading and updating and lock it so that other processes can't change the file between my read and update cycles. I'm running the code on a Debian GNU/Linux box with Python 2.3.
I think I may release 1.0.1 this weekend depending on what else is going on life-wise. I tossed a feeler email out to the dev list in regards to what else should be fixed for 1.0.1, but didn't get anything back--which isn't surprising as people are pretty busy these days.
So... to do a release or not--that is the question. Is there anyone reading this blog who has things that they'd like to see for a very minor fix-it point release that's doable by one man who only has a bit of free time (unless they're interested in sending in a patch)?
Last night I did a lot of work on my registry plugin. I'm completely re-writing it from scratch--how it works, what it does, so on and so forth.
One of the things I never bothered to do was separate my blog (what you're looking at now) from my development. So whenever I make a mistake and create a bug, my whole blog goes down. Sometimes, in the case of last night, interesting things happen. I was playing with FileEntry and the generation of the absolute_path which had the effect of mucking up all the categories and permalinks on my site.
Anyhow, so things go up and come down pretty often on this blog since it's very very bleeding edge in terms of the source code and I'm often editing things live.
Having said that, I'm almost done the new registry plugin. I'll install it on Planet PyBlosxom soon and overhaul all the existing registry entries. This version of the registry plugin will make it easier to do a flavour registry as well. It's also a heck of a lot easier to set up and maintain.
I've been asked a couple of times for the templates for the HTML flavour of my blog. So here is a tar.gz file of them and the stylesheet.
A warning to folks who download that file: the templates and stylesheet aren't wildly pretty. I'm not a web-designer--I just pretend to be one.
I'm on the mailing lists for OZ and OE because I own a Sharp Zaurus 5600 and at some point I'll have some time to play with it enough to get it to the point where it helps me in my daily life. I haven't had any time to devote to it in the last four months though, which is unfortunate.
Anyhow, someone on the openzaurus-users mailing list complained that there's no support for the 5600 to which Michael (one of the three and a half people who worked on OZ) responded, expressing a lot of frustration, then said this (and I'm quoting him slightly out of context):
And just to prevent misunderstandings, I don't want to be thanked for all the work... I don't want anything at all except participation. I want to work in a team bringing the community forward - I want people to realize, they're not helping _us_ to produce a great handheld operating system, they're helping _themselves_ and by doing that, helping each other. After all, this is what I thought was open source.
On all of the projects that I've been a part of or led, that's exactly what I hoped and prayed would happen. I have a couple of projects right now where there are people interested, but nothing is happening because I'm not driving it [1]. Those projects will die because I'm just one man--I can't drive all projects I'm involved in unless I quit my job (which is the only income stream I have).
I'm not sure that's what open source is. But I wish more community sprung around open source projects. My experience has been that people just want the features they want. They're demand-oriented consumers and it boggles their minds that I haven't coded up their favorite feature. It's so ego-centric. There's a big world out there! 6.5 billion different lists of favorite features!
[1] I'm not even a great driver--I'm ok and I get things moving forward, but I certainly lack the finesse that I've seen other project drivers use. For example, Bruce Perens guiding UserLinux is riveting. I suspect that I drive through sheer force of will rather than sheer leadership--which doesn't really do anyone much good.
I've noticed while working on PyBlosxom that bugs can literally be reported anywhere. Not only that, but people get annoyed (really annoyed) when you don't respond to their bug report which was reported using a method that I never would have dreamed of. We've had reports in all the following places:
It takes a huge amount of time to check all these places--many of which come and go. It really puzzles me why people don't try to be more social and send bug reports via channels that other projects typically use (bug trackers, mailing lists, and IRC). I've been trying to coerce people into a few standard channels, but it's really hard on a project like this and there's a lot of resistance.
Bottom line is that this kind of thing really affects the project's quality. There are bugs out there that I will never trip over that someone else did but because they chose to whisper it into their pillow at night rather than tell someone about it, the bug won't get fixed and will trip someone else up.
I thought blogs were supposed to be social tools to enhance communities and promote discussion.
Anyhow, we can only do the best that we can do.
We've cleaned up a lot code and documentation and fixed a lot of bugs. We've stabilized the API and added static rendering. In short, this should be a pretty solid 1.0 milestone for PyBlosxom.
I encourage people to upgrade. When you untar the distribution tarball, read through INSTALL and README. These files will walk you through installation and upgrading from 0.9.
Download it at https://sourceforge.net/project/showfiles.php?group_id=67445.
Personally, I'm glad we finally pushed out 1.0. I'm not sure it's a perfect release, but it's good enough for a 1.0 milestone and I feel good about releasing it at this point. It's hard to push a project through to a release when there's not much feedback from testing and usage of previous alphas and release candidates. I think at some point you just have to bite the bullet and push it out and see how it does.
Cheers to the PyBlosxom development crew!
I'm releasing pyblosxom 1.0 RC1 right now. I overhauled the callback documentation in the ReadMeForPlugins file and read through other documentation and I think we're good enough for a 1.0 release now.
The RC1 is at http://bluesock.org/~willg/dev/pyblosxom/pyblosxom-1.0-RC1.tar.gz.
Feel free to download it and test it out--it's very much like alpha1 with a few differences:
That's about it, I think.
In the tar.gz file is an INSTALL file which details installing PyBlosxom. There is also a README which talks about differences between 0.9 and 1.0 (which will help you upgrade an existing PyBlosxom installation).
Let me know what you think. I plan on doing a 1.0 release in the next few days. Probably Thursday.
We're working to put out PyBlosxom 1.0 which should be coming out very soon now. I'm in the process of overhauling all the documentation and doing some minor tweaks.
If you have comments/feedback/problems, toss me a comment and express them here.
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.
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.
I mentioned the Debian reference card a while back and my roommate found a vi/vim reference card for me. Fantastic!
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.
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:
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/willg/public_html/cgi-bin/
./pyblosxom.cgi --static
find /home/willg/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).
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:
If I want to completely eradicate the plugin:
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.
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.
I have a statically rendered version of my site at http://www.bluesock.org/~willg/test/. The links on the right side are a bit off--but that's a problem with my flavour templates and not the static rendering code.
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.
I hacked for 3 or 4 hours on static rendering today. Almost have it complete where "complete" is defined as "statically renders your basic blog into html and other flavour forms" and is not defined as "handles dynamic content, comments, and other neat things seamlessly".
I think that'll all be in version 2.
In the process of implementing what I implemented, I moved some stuff around, cleaned up the common_start stuff, re-tested xmlrpc, removed some old files in the CVS repository, and fixed some bugs that had been lying around undiscovered.
Assuming I get some time tomorrow to work on it, I'll have static rendering finished before the end of the weekend.
I just made a bunch of changes to PyBlosxom and figured I'd test to make sure xmlrpc still works...
The mailing list has been really active. There is definitely a BIG correlation between mailing list activity and my motivation towards fixing things. Some of the things Eugene has said have irked me, but in general he's providing a lot of solid observations which (I think) have led to some really great changes.
In the last few weeks, we've:
All good stuff none of which would have happened with a quiet mailing list.
I added the Request object to the locals for eval_python_block. I also did away with the "printout" kluge I had--you can use print now.
If you used an old version and are upgrading to this version, you'll need to convert all your "printout" function calls to regular print statements.
Find it in my plugin index.
I've never really liked Java much. After using Java for 5 or 6 years in various projects, I can count the number of times I've been working on something in Java and thought to myself, "Gosh--I'm really psyched I'm doing this in Java" on one hand. I dislike it a lot less than C++, but I'm not sure that really counts for much. I'm ok with the language semantics--it's the API that really gets me.
Anyhow, the Javahut story in this article is pretty much what I'm thinking when I'm dealing with Java. To quote the passage:
Imagine if the Perl cafe and Javahut were across the street from each other. You walk into Javahut, and ask to sit down. "I'm sorry," says the person at the door. I'm not actually the hostess, I'm a Factory class that can give you a hostess if you tell me what type of seat you want." You say you want a non-smoking seat, and the person calls over a NonSmokingSeatHostess. The hostess takes you to your seat, and asks if you'll want breakfast, lunch, or dinner. You say lunch, and she beckons a LunchWaitress. The LunchWaitress takes your order, brings over your food, but there's no plates to put it on because you forgot to get a CutleryFactory and invoke getPlates, so the Waitress throws a null pointer exception and you get thrown out of the place. Dusting yourself off, you walk across the street to the Perl cafe. The person at the door asks what kind of seat you want, what you want to eat, and how you want to pay. They sit you at your seat, bring over your food, collect the money, and leave you to eat in peace. Sure, it's not the most elegant dining experience you ever had, but you got your food with a minimum of pain. -- James Turner
That sums up my feelings on the whole Java thing. Mr. Turner deserves a gold star.
The bigger problem (and I think this is inherent in the Java community) is that there are all these Java developers who think in terms of massive object hierarchies and comprehensive APIs for every project. It takes forever to write the infrastructure that expose all the bits of data and functionality so that you can write the program to solve the problem.
Blech.
Conan had sent me MCCP handling code back in August or September. It took a while to design the filter hooks that needed to go into Lyntin 4.0 to accomodate network-level data fixing (encryption, compression, ...). After I had added those filter hooks, I never quite got enough time to sit down and finish up the MCCP module...
Until now.
Find the first draft of the Lyntin MCCP module here with the rest of my Lyntin modules and rejoice that I finally got this off my todo list! w00t!
Yay--it's released! Now I can sleep at night again and dream of iplementing static rendering.
After a hiatus, I made some changes to the Lyntin website after looking at the groovy web-site which I discovered after reading Ted's blog.
It's interesting how I can work on something for tens of iterations honing it here and tweaking it there. Then I'll see something that's very similar to what I'm doing and suddenly everything clicks and *voila* I realize what big changes need to be made for a dramatic improvement.
Anyhow, there's a bunch of stuff in CVS for Lyntin that should get summed up into a release. I may tackle Telnet LINEMODE handling (which really needs to get done) and also the MCCP plugin. Eugene has a really slick curses ui which I think has reached a point where it should get included in the main distribution.
Things are afoot once more!
A couple of weeks ago, I checked in code to help out PyBlosxom installation and configuration. I made changes to pyblosxom.cgi so that you could run it from the prompt:
./pyblosxom.cgi
It tells you your Python version, OS name, and then proceeds to verify
your config properties (did you specify a valid datadir? does it
exist?...) and then initializes all your plugins and executes
verify_installation(request) on every plugin you have
installed that has the function.
As a plugin developer, you should add a verify_installation function to your plugin module. Something like this (taken from pycategories):
def verify_installation(request):
config = request.getConfiguration()
if not config.has_key("category_flavour"):
print "missing optional config property 'category_flavour' which allows "
print "you to specify the flavour for the category link. refer to "
print "pycategory plugin documentation for more details."
return 1
Basically this gives you (the plugin developer) the opportunity to walk the user through configuring your highly complex, quantum-charged, turbo plugin in small baby steps without having to hunt for where their logs might be.
So check the things you need to check, print out error messages
(informative ones), and then return a 1 if the
plugin is configured correctly or a 0 if it's not
configured correctly.
This is not a substitute for reading the installation instructions. But it should be a really easy way to catch a lot of potential problems without involving the web server's error logs and debugging information being sent to a web-browser and things of that nature.
I keep getting into the classic "your language sucks; mine is better" discussions with various people. Regardless of what they say, I still like Python, C, sort-of like Perl and dislike Java. Some day when I have a free moment or two, I'll remember/learn enough SML/Lisp to like that again as well.
I decided the registry plugin needed to allow users to see all the pending submissions and details therein. So I made some changes:
Get it on my pyblosxom page.
We're almost done with 0.9 and the code is baking in CVS and Ted is doing all kinds of crazy stuff with metaweblog, comments, and his Lucene search plugins. When that all gets sorted out, then we'll do a release which has been a long time coming.
In the meantime, if you want to try out what's in CVS, here is a snapshot as of February 24, 2004. Setup is just like PyBlosxom 0.8.1. Features for users are pretty much the same. Biggest changes are architectural which will enable plugins to solve a very wide variety of problems and do all kinds of exciting stuff.
Official announcements and all that on the PyBlosxom site soon. Additionally, I've been working on Planet PyBlosxom, which will provide a centralized newsfeed of PyBlosxom stuff from PyBlosxom users' web-sites via their RSS feeds.
I just finished making a bunch of code changes. So if you go this route, you may encounter problems. Having said that, feel free to email me or the pyblosxom-users mailing list with questions. It should be noted I'm posting this entry with w.bloggar right now.
The w.bloggar account settings should be as follows:
In the Content Management System section:
In the API Server tab:
In the Custom tab:
When you go to write a new entry, leave the title field blank and do your entire post in the data section with the first line being the title (just like blosxom entries).
One thing you should note is that pyblosxom will take the first line and use that to generate the file name of the entry. So if the title of the entry is "How to use w.bloggar with pyblosxom", the file name ends up being "How_to_use_w_bloggar_with_pyblosxom.txt" which is a little annoying but whatever.
That seems to work for me. Poke me if you have questions and I can update this entry with the adjustments.
This is a test post from w.bloggar testing out my new xmlrpc and xmlrpc_blogger plugins.
Date: Sat, 14 Feb 2004 11:14:01 -0600 From: brian To: will Subject: Version control Is a magical, wonderful thing. Don't let 'em tell you any different.
This is a better columnize function. Though I'd be curious to see which one was "faster" to process. Next rainy day I get, I'll benchmark them.
Theoretically, I just got w.bloggar working with my blog. There were some minor fixes I had to do to the xmlrpc lib we have in PyBlosxom. I'll be checking these changes in.
Beyond that, I wanted to see what the tool actually did. Where does it put the file? What does the file look like? What's the name of the file? So on so forth.... Enquiring (or is it Inquiring) minds want to know!
On Friday, I sat down at my desk at work, put my coffee mug down, and went to scratch my eyebrow when suddenly the lens fell out of my glasses and the tiniest screw in the universe dropped almost unnoticeably to the desk in a beautiful swan dive. This surprised me greatly and led to three different epiphanies:
Anyhow, I was amused to discover that Ted also had vision problems. We're like TWINS!!!
I got home today and totally forgot to fix my glasses until I had been sitting here for 10 minutes staring at this weird bug I found (or thought I found) in PyBlosxom that was happening in one of my blogs but not the other. The PATH_INFO for the url http://blog/george/sophia showed up (incorrectly) as "/blog/george/sophia.txt" and for the other showed up (correctly) as "/blog/george/sophia" Both blogs were configured almost identically, so I was perplexed. Then I realized that it was just me doing something totally stupid. That's when I remembered that I had to fix my glasses. So I pulled out one of my jewelers screwdriver kit (I have several--one of which I should bring to the office) and pulled out a perfect screwdriver, fixed my glasses and marvelled at how a screwdriver of the right size can make all the difference in the world.
To summarize, my glasses are fixed, I fixed my configuration, PyBlosxom doesn't have a bizarre PATH_INFO bug, and I learned that a paperclip can be used as a quick fix.
There are some minor tweaks, but more importantly, I added the ability to evaluate python code blocks in the static page. Find it in my plugin index.
I whipped up a plugin that changes the renderer to the debug renderer if there's a "debug=yes" in the querystring. It's not wildly exciting, but it works nicely and I can debug things without necessarily taking my entire blog down.
Get it at my plugin index.
I'm on this crazy coding kick right now. For some reason I decided to go dig up Stringbean and see how it was doing. It's doing fine! Well, except for the fact it wouldn't start up. So I did some fixing and now it's fine and starts up and everything seems hunky dory. I have no clue what I was working on last.
Anyhow, for anyone interested, here's a tarball of a working, but very lacking, version of Stringbean. I release it under the GPL. I might at some point work on it some more, but if not, there it is.
I just added locking to Pyblosxom to allow separate Pyblosxom requests to synchronize on centralized data. In my case, the data is a file of how many views each of my blog entries has gotten. It seems to be pretty functional. It's something I had coded in my viewcounts plugin, but I've moved the code (and added to it) into the tools module so we can all use the same base.
An example of usage is this:
from Pyblosxom import tools
LOCKNAME = "viewcounts.dat"
...
lockret = tools.get_lock(request, LOCKNAME)
if lockret:
# yay -- we have the lcok
else:
# foo -- we don't have the lock
...
if tools.has_lock(request, LOCKNAME)
# yay -- we have the lock
else:
# foo -- we don't have the lock
...
tools.return_lock(request, LOCKNAME)
The code is in CVS. It'll go into the next version. Also, I added a unittest module to the code base.
I've been in some kind of neat motivational kick the last few days to update my plugins. This time, I've overhauled the registry plugin that Wari uses for the Pyblosxom web-site.
Changes:
Anyhow, if you were one of the one or two people that were using it, this is definitely worth updating to. If you need help reconfiguring it or if you have problems, let me know.
It can be downloaded at my pyblosxom page.
(snuck it in just before the end of the year--yay!)
I was poking through other peoples' blogs and bumped into one that mentioned a bunch of things I should do to my booklist plugin to fix it. One of which involved switching it from hard-coded html to use pyblosxom flavours. So I did that work and some other neatening up and released it. Get it on my pyblosxom page.
I went through and added the MIT/X License text to all my plugins and updated them with some minor bug fixes and additional features.
My pyblosxom stuff is here.
It's nice to release things. Check the website for more details.
Reading this and this was super! But I have to add the following which account for almost all the bug/feature related emails I get:
The last one is totally true. But it's not because I'm a bad person--it's more because I'm pretty much a one-man band and I just don't have time to do everything, so some items suffer until enough people complain (or better yet--contribute).
With Lyntin, I think I've got a really decent user base that's pretty able considering that the documentation is fairly lacking. I wish they were a bit more communicative, but otherwise, it's perfect for my tastes. Easy to deal with, friendly, mature, not overly needy, and pretty supportive. It's one of those things that I think would be somewhat spoiled if I lowered the bar of entry to using Lyntin by making it all user-friendly and such. Who knows? The main important thing to keep in the back of everyone's mind is that Lyntin development is so totally not my day job and I'm more interested in a sophisticated framework than I am in a fancy user interface.
There's something wonderful about releasing software. I think it's probably the relief associated with throwing it to the world and knowing that you're done with it. Of course, in this case, since it's another beta, that isn't entirely the case. Though I don't plan on touching it for a few days, at least.
Anyhow, more information at http://lyntin.sourceforge.net/.
Now I'm going to take a nap and get my clippers and go to a party because I get to sleep an extra hour tonight. Whee!
So I've been lurking on python-dev for almost a year now. I think it's been a year--might be more. I forget. My friend just sent his first post to python-dev. This is what he said:
I'd like to suggest "outer v" for this. The behavior could be to scan outward for the first definition of v. If the only outer-scope variable is at module-level, then the behavior would be the same as "global v". Or if everyone is comfortable enough re-using the keyword "global", then I also like "global v in f".
It was pretty exciting. So I asked him how he felt. To this he responded, "naked".
I'm on vacation right now. In fact, today is one of two days it's actually been sunny. Instead of sitting outside, I sat down and implemented registry entry editing--something that's been sorely lacking. Unfortunately, the hacks I just did to get it to work are really icky. A small part of me wants to sit down and refactor it right now, but the other 90% of me is thinking that I don't have vacation very often... Refactoring can wait.
It's been a long time coming, but I keep getting bogged down in other projects. I'm only releasing a tar.gz file. I wanted to do a Windows installer, but I can't seem to get an installer that builds a desktop shortcut. I don't really want to keep throwing time at it either. So if you're inclined to tackle this issue, let me know.
Things in this release:
If you discover bugs or have other problems, let me know. I'm on vacation 9/24 through 9/30--so email sent will likely get queued until I read it.
Rock on!
Date: Tue, 05 Aug 2003 22:04:59 -0700 From: project-purge@sourceforge.net Subject: SourceForge.net Project Removal Greetings, ... The varium project on SourceForge.net, originally registered on 2000-01-14, meets the criteria we have set up for this purge. If you fail to respond to this inquiry, your project will be removed in approximately 21 days. A final warning will be sent in approximately 14 days if we have not yet heard from you. ...
I worked on Varium with Josh and Pat for a couple of years. The project started out in C, then we talked about embedding Perl, then we switched over to writing the whole thing in Python. That was in the end of 1998. It's what got me coding in Python and also what got me working on apsects of mud development--a hobby I continue to this day in several forms which has helped significantly with my career and growth as a developer.
Even though I stopped working on Varium in 2000 and started working on bluemud (another Python-based mud server) and then left that project to work on stringbean which hasn't really gotten very far (for all kinds of really good reasons), it's sad to see these sorts of beginnings finally pass into the quiet of the night.
I have access to the code-base if anyone is interested. As Josh pointed out, there's very little documentation (i.e. almost none), the code-base is messy, and it was written in the days of Python 1.5.2 when I (and likely my cohorts as well) didn't really know what I was doing in Python land.
Read the ChangeLog for gruesome details.
This will be the last release before 4.0 which is scheduled around October 2003. There's some heavy things that are in the plans to be redone between now and then. Read the roadmap for more details and watch this site for news.
Thanks to the folks who helped make this a clean release--their help in the last few weeks discovering and diagnosing bugs has been great!
This plugin handles registry kinds of things. I use it (now) for the Lyntin code registry. It's soooo much easier to deal with than the one I wrote in PHP.
Code here.
I checked in some changes I made last night which affect how variables get expanded and what kinds of things we can do with metadata variables. Now, we can expand the following variable things:
| $foo | This is a regular variable with nothing fancy that we could handle before. |
| $foo::bar | This is variable bar in the scoping foo. Variables can now be grouped in categories. Categories can be functionally oriented (utils, calendar, date, file, communication, ...) or plugin oriented (pycalendar, pyarchives, ...) or whatever. |
| $foo::bar("arg1", "arg2", "arg3") | This is variable bar in the scoping foo... but it's actually a function call passing in three arguments all of type string. The arguments are evaluated as Python code, can be of any type, and any quantity. We only pass in the arguments if the value of the variable (in this case $foo::bar) is a function. This allows plugins to take in configuration information from other places other than config.py. For instance, this is really useful for a fileinclude kind of plugin where you might want to include different files at different points in your templates.... More about that later. |
So now the following examples are all valid variables:
In typical fashion (and at Wari's behest), I wrote a quick plugin which uses this. It allows you to include files in your head and foot templates. I use this to include my .project file so people can see it on my web-site as well as finger me on my server and I only have to update it in one place.
Code is here.
It's threatening to snow outside. Normally this sort of thing doesn't occur so it's a bit bizarre. Not to mention the fact that it'd be nice if it was nice outside. On the flip side, since I'm at work all day and the only windows in my cube are the ones on my monitor, I'm not wholly sure I care.
I read a terrible article on Freshmeat about Open Source software. The dude says he's a software engineer and that he was "enlightened in 1997 by Free Software" (capital letters and verbiage are his) which is silliness. If he was "enlightened" and really understood the motivations of the hundreds of thousands of faceless developers out there silently (from a media perspective) working on open source software, he'd never have written this article. He'd have known about the synergy that occurs between projects who have some similar goals as they learn from each other--both mistakes and successes. He'd have known that most of us are decent developers looking to learn more about development--that many projects are done to learn--that the production is far far far more important for the developer in question than the product. He'd have known that most developers are not magic makers--that most of us specialize in a few aspects of software development and that a TEAM of people is responsible for a solid product that has solid design, solid goals, solid functionality, solid unit testing, solid documentation, and solid support. He'd have known that as a project matures and evolves as a function of its user base and its usage, it hits a point where the code becomes unwieldy and it needs refactoring. Sometimes it needs to be rewritten. This is good. He'd have known that there are a bunch of http software projects--with different missions and different characteristics. He'd have known the same about SMTP MTAs, database servers, and various other server components. He'd have known a lot of things. He's enlightened for incredibly loose usages of the word enlightened.
This plugin registers with the prepareChain and injects an entry to the beginning of the entry_list that holds personal information from $datadir/personalinfo.dat which is a pickled dict. I have mine updated via cron at the moment.
I don't really have a wild need to have this information, but it occurred to me that our system allows for this without any problems. I mentioned this to the pyblosxom-devel list and Ted replied that we need more examples. I thought about it during lunch and then whipped together this example (it took 10 minutes again--I'm into these 10 minute plugins at the moment).
3/19/2003 - Moved code to /~willg/dev/pyblosxom/ .
1/27/2004 - Removed because it's a sucky plugin and there are better ones.
This one counts the number of views for a given entry. It only counts the entry if the renderer asks for the $viewcount value. At that point, the viewcount module will figure out how many views this entry has had (using the id on the entry), add one to it, save the new value, and then return the new value to be displayed.
3/19/2003 - Moved code to here.
4/8/2003 - Updated code to new architecture.
This plugin registers with the prepareChain and for each entry it adds a $wc metadata variable. The wordcount is sort of an expensive process since it requires the data of the entry to be populated and we only populate that on-demand. Thus we need to populate the $wc variable on-demand as well.
...
The effects of this is that I can add a $wc variable to my story.html template file and you see a wc: thing on all of my entries.
This plugin and the entry that describes this plugin were written, tested, and documented in 15 minutes.
3/19/2003 - Moved code to here.
4/8/2003 - Updated plugin to new architecture.
I just finished the last bit of the overhaul that Blake started which involved separating retrieval of content from content rendering. It's super cool because now content can come from anywhere--it's no longer tied to a single datasource (sql, file system, ...).
I also just promised to name my first born child the be-yoo-tiful name of "xmlrpc_username". I think the way it rolls off the tongue ... it ... it just brings a tear to my eye--it's so beautiful.
I also wrote a plugin that looks at the url to see if it's "/plugin_info" and if it is, then it will build a series of entries based on the installed plugins:
...
You can see it's output here. How do you like them apples?
3/11/2003 - Fixed the code
3/19/2003 - Moved code to here
I've been kind of dragging my feet about releasing Lyntin 3.2 because I haven't been getting any feedback from the community. So either no one is using it, or no one replies on the mailing list. Oh well--what can a developer do?
This release has some really great features. I added a scheduling system and re-wrote the ticker to use it. I wrote a #schedule command which allows you to schedule events to kick off using one of several time specifications. It's also got a new #grep command which goes through the databuffer and allows for printing of match context. There are some bug fixes and some refactoring and stream-lining. For the most part, it's a clean-up release.
And now I'm going to kick my feet up and work on all the other things that I've been neglecting.
They really do. Case in point, take this conversation on the Necro guild line:
Chats (last 15 of 102 available):
Nabiki [19-L]: ive never played that
Nabiki [19-L]: better get my booty to raylorn
Rapocco [33-P]: is there an info file?
Flamerus [13-V]: k but i need a min xplainin vamps to a friend
Shadowhawke [Lady]: the instructions are there, it's fun!
Saidin [Marq-V]: bah boot
[->GUILD<-]: Halix rises from the crypt.
Halix [13-V]: lo all
[ 7:30pm ]
Flamerus [13-V]: lol
Macros [30-P]: Hi Halix
Flamerus [13-V]: ne1 else want to play???????????????????
Flamerus [13-V]: morion go to courtyard(1st)
Flamerus [13-V]: there r instructions u can read
Morion [21-W]: ah :P
One substitute command later and I now see this:
Chats (last 15 of 102 available):
Nabiki [19-L]: ive never played that
Nabiki [19-L]: better get my booty to raylorn
Rapocco [33-P]: is there an info file?
two-year-old [13-V]: k but i need a min xplainin vamps to a friend
Shadowhawke [Lady]: the instructions are there, it's fun!
Saidin [Marq-V]: bah boot
[->GUILD<-]: Halix rises from the crypt.
Halix [13-V]: lo all
[ 7:30pm ]
two-year-old [13-V]: lol
Macros [30-P]: Hi Halix
two-year-old [13-V]: ne1 else want to play???????????????????
two-year-old [13-V]: morion go to courtyard(1st)
two-year-old [13-V]: there r instructions u can read
Morion [21-W]: ah :P
I've finished all the programming for Lyntin 3.2. I plan to release it next weekend. Between then and now if you want to grab the latest in CVS and test it out and report bugs, that'd help a great deal!
Things that Lyntin 3.2 will have:
There's some neat stuff in here and some minor optimizations and fixes to documentation as well. It'll be a good release.
(Mark made me do it.)
It was the nicest, most informative bug report I have ever gotten. I felt obliged to release a fixed version since I've known about the bug for a month and wasn't ready to release 3.2 yet.
The only difference between Lyntin 3.1 and 3.1.1 is the fixed #config command when you don't have any readfiles or moduledirs set at the command line. Well, that and I adjusted the information in #version as well so we don't go calling two different releases of Lyntin by the same version number.
I'm in some kind of Lyntin development kick again. I implemented all the changes I talked about in yesterday's email:
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:
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.
I wrote a tutorial on writing basic Lyntin modules. Hopefully it helps to fill a void in coming up to speed on Lyntin module writing. I'll probably add more tutorials as time goes on... Oh. Now that I think about it, I should have the Lyntin site just grab my RSS feed for the status. Mmm... I'll have to toss that around.
I re-wrote my calendar utility (which tells me what my schedule looks like when I log in) in Python. This is good because I haven't touched Perl in some time and I wanted to add some other formats to it (like handling "second thursday" and "*/15") and I wasn't looking forward to figuring out what I wrote many years ago.
I also re-wrote my logger at work. It's not really a logger--it's more of a log extrapolator. It takes all these fun bits and puts them in places where I can glance over them quickly and guess at what happened rather than reading all the gory details and know enough to write a thesis.
Then I wanted to add a calendar to pyblosxom. So I adjusted the code to handle drop-in plugins and threw together a pycalendar thingy. It's not great but it works and it's not half-bad for an hour of coding.
I've just felt really inspired lately. I cruised through a color overhaul which fixed the totally borked handling of color formatting I had in there before. I also added a NamedWindow class to the tkui which is kind of neat. If that wasn't enough, I added bell handling and fixed up some stuff to make telnet control code issues easier to discover.
I've got a lot of changes. I think I'm going to release a 3.0.1 really soon.
At some point, I hope I feel motivated to do the distutils stuff. I haven't even researched it enough to figure out if we want to be doing distutils stuff or what code changes it would entail.
I fixed some issues with telnet control handling which were borked. I also adjusted some things so that we show up more favorably on the Cryosphere mud client support table after talking with the maintainer of that table. I may look into adding some more features based on that table--like NAWS support. The existing problem is that for the textui, I can't seem to determine what the LINES/COLS numbers should be if you're running Lyntin over telnet/ssh. I'm tossing around adding hooks for telnet control negotiation and changing the MudEcho handling to use this hook instead. That'd open up the possibility of creating something like a wxPython ui which is completely xterm compliant. I have to toss this around a bit more. I also want to enable logging of incoming telnet control code sequences so I can see what's going on.
I finally added Sebastians patch for regular expressions in highlights, though I made some adjustments to account for the current codebase (the patch was from like 6 months ago or so) and also to use our regular expression syntax instead of a toggle on the Session.
It's slick! The regular expression implementation is also faster than my original string.find implementation. Doing something like this:
> #highlight red e
lyntin: highlight: {red} {e} added.
> #highlight green i
lyntin: highlight: {green} {i} added.
> #highlight blue a
lyntin: highlight: {blue} {a} added.
doesn't tax Lyntin as much as it did with the string.find method. I kind of wish I had done this a few months ago, but didn't really get around to putting in the time to figure out what needed to be done. I think I'm going to overhaul substitutes/gags in the same way next.
I just finished released Lyntin 3.0 (there's another blog entry on that specifically) and I'm all excited now! This is the first time that I've guided a non-trivial project from start to finish where I had a hand in everything--documentation, site development, architecture, feature design, bug fixing, testing, development, working with other developers, answering user issues, ... 15,000 lines of code.
Anyhow, on to other projects for a while as people pick up Lyntin and the community grows a bit. I've set out to do everything I wanted to get done. I still have some things in my roadmap to work on, but they can wait.
On to Stringbean and the dozen or so other projects that are waiting in the eves!
I finally released Lyntin 3.0 (final). Now I'm going to have a glass of wine, kick my feet up, and read GoTo while listening to Jacqui Naylor. I started working on Lyntin 3.0 in September of 2001--it's been 14 months of development. It was worth it.
It's true. I started to add Callout functionality, but also started splitting the driver into a driver and a mudlib, renaming driver.world to driver.engine, adding a mudlib.world module with a World object in it (and moving functionality from the old world to the new world), and a series of other things. All of this will take some time to sort through. I'm also looking into adding a series of hooks to the driver to tie the mudlib into the driver. The good news being that Strinbean will be pretty nice once all this is done.
I went through and overhauled the FAQ and then updated all the existing Lyntin documentation. I also moved some information around between things.
There are some things I want to clean up, but I think I'll be doing a 3.0 release in December--probably this weekend or next weekend. After that, it'll be a series of minor point releases whenever we accumulate enough stuff to make a new minor point release. We'll do major point releases whenever we make enough architectural changes to warrant such a thing. After 3.0 is released, emphasis will go towards generating some more documentation on building Lyntin modules as well as fixing the existing modules that I've created and haven't really updated in a while.
All in good time. All in all, though, things are looking extremely good. Today I implemented a quick module to tell me if I have new email. I wrote it in the space of 5 minutes and it works wonderfully.
I got my Python Cookbook in the mail and I've been reading through it and as I've been doing that I've been revising bits of Stringbean accordingly.
I also finished up a basic emotes module, adjusted the startup code, added handling for multiple names, added drop-in modules, added a command manager, added commands on objects/rooms, and started a driverapi module for abstracting driver code from its own implementation.
Wesley's been helping finding multi-session issues. We ended up implementing readline in the textui, echo in the textui, #snoop command for disabling snooping on non-current-sessions, message scoping for LTDATA messages, and fixed a bunch of bugs as well. I also fixed up my repository script on the web-site and coallated all of Sebastian's emails into one big file which I plan to read through and verify I completed everything he's been asking for over the last year.
When all that's done, I'm going to take a break for Lyntin for a while and fix minor bugs and otherwise let the code-base bake.
I redid exits, command handling, descriptions, word wrapping, and a few other things. Then in the tavern I'm working on, I added tables, a hatrack, a guestbook, a grandfather clock, and Neil who sits at his bar and waxes philosophical about the old days.
All in all it's coming along very very nicely. There are a few things I need to change to improve command handling and looking at things. Then to work on more complex issues.
I added NPCs with heartbeats, adjusted the command handling a bit to account for exits a bit better and fixed a bunch of little things. I'll probably build a list of things I want to do which will probably hinge around adding new things to the world.
Well, I haven't touched Lyntin in the last week because I've been busy doing that work and that holiday thing. But now the plan is to go through all of the Lyntin-devl email, look for issues I missed, toss them all in one big todo list, and adjust the roadmap accordingly. Depending on how that goes, I'll be releasing Lyntin 3.0 in the next few days.
It's been a really long road (14 months or so now) and it'll be nice to finish it and get it out the door.
So I was putzing around overhauling old Varium code which I haven't really touched in a couple of years when it occurred to me that the code I'm overhauling involves features I don't really care about--at least not at this stage of the game. This sudden realization caused me to re-evaluate what I was doing and take a new approach.
I took the testserver I wrote for Lyntin and expanded it into a series of modules and 1300 lines of code later I now have a working mud that has multiple rooms, heartbeats, multiple players, and a series of other things. More importantly, it gives me a good base to add on new features as I need them--giving me time to architect things as I go along rather than doing the whole thing up front.
I need to do a few more things before it has enough of a a critical mass to be interesting.
I bumped into a full explanation of escape codes in xterms and it occurred to me that I could set the title bar of the xterm session and thus have a non-moving status bar of sorts in the textui. I spent 5 minutes slapping together a module that sets the title bar for the textui (if you're using an xterm) and the tkui with name/value pairs that you set using the #setstatus command.
Link to said module is here.
Incidentally, the ability to whip together additional functionality like this in such a short period of time is what makes Lyntin such a powerful mud client.
Just did some additional edits to the hooks which fix some potential race condition problems between when Lyntin core hooks get instantiated and when they get registered with the HookManager.
Left to do:
After talking to Josh for a bit, we decided that we should overhaul hooks a bit before putting out 3.0. The reasons for this are mostly that the existing hook system didn't allow module developers to build hooks easily and have those hooks referenceable by other modules written by other developers.
I just finished coding up the HookManager class which holds registered hooks. Hooks can now be retrieved via the old method (accessing the Hook directly) or alternatively through the exported module which talks to the HookManager which knows about all registered hooks. I spent some time overhauling the existing Lyntin code to account for this adjustment and it's working nicely so far.
Hopefully this is the last big issue to solve before 3.0. It needs to sit and cook for a bit, though, so this will push the 3.0 release off at least a week--possibly more.
We had this idea to overhaul the logging functionality so that it's in a manager just like most of the other functionality. I just finished this up tonight. I'm tossing around other arguments you would want to pass on the command line--haven't gotten there yet.
The next big issues:
There isn't much progress on Stringbean yet. I do want to re-tackle it when Lyntin 3.0 is released and development dies down to a slow murmer. The first thing I'm going to do is overhaul all the Varium code and include a lot of the changes that I made for Bluemud (ansi parsing, word wrapping, ...). Then build an online tavern from that. It's not going to be much of an adventure mud from the beginning--I just want somewhere I can hang out with cool people (online).
I was looking to release 3.0 this week, but I'm going to re-write the ticker functionality and the logging functionality so they're both managers. I also want to investigate decoupling hooks from the hooks module or at least provide some registration mechanism so that module writers can create their own hooks and access hooks written by other module writers.
I also want to review all the mailing-list archives for things I intended to do, but then didn't do as well as Sebastian's emails to see what ideas he had that are now appropriate to do.
So this is my first post with my new blogger. I switched from a partly hacked version of Steve Gutenberg's weblog thing to pyblosxom which allows me to do blog entries with standard text files and a bunch of other stuff.
Unfortunately, it's going to take a bit to get things converted over and settled. We shall see....
Coding is an adventure in formal logic and intellectual pointedness. As in anything else, the more you know and have experienced, the easier things get. I want to hit the point where I have seen so much in my lifetime that I can come across any new problem and after applying a sufficiently complex isomorphism understand the new problem in terms of older problems. That's the goal. Of course understanding and solving the problem don't necessarily play on the same team.
Programming is not so much like building a tower of metal and steel. It is more like looking at the canvas for long periods of time. Visualizing the stroke--the single stroke that you will place there. You think through all the motions involved in the stroke. How it fits with the canvas. How it fits with the world. The curves in the stroke, the straightness. And then suddenly, you draw that perfect stroke. But it involves seeing the whole canvas to begin with.
Beautiful programming is a lot of meditation and thinking and about precise deft strokes, not a bazillion tiny little hacks that barely form a structure that can withstand use and abuse.
But beautiful programming does not happen in practice and it's not efficient in the sense that the initial cost is really high--even though maintenance and related costs would be low.
How does one reconcile this with business and society and work? One tries to keep this in mind. To keep patience in the soul as they build and debug and observe and analyze. All things happen because they are written in the code as such. It is our jobs to make deft accurate strokes rather than practice black magic and voodoo and make a billion inaccurate strokes in a frustrating attempt to solve the problem quickly.
Of course, as with all things, there is a time and place for voodoo debugging.
Update 12/9/2004: Everyone goes through a "programming is beautiful--I'm an artist!" phase too, apparently.
I was using telnet to connect to this mud I play on and I got tired of telnet. So I started looking around for solid mudclients and found a few--but they were either flakey or bloated or shareware or lame or any number of a myriad of bad things. I decide to roll my own and do it in Python. Then I discover Lyntin--this mudclient written in Python and the maintainer hadn't touched it in months. He hands over the maintenance of the project to me. I move it to Sourceforge, put out a few versions, fix a few bugs, and voilla! I have a solid mudclient.
Then I start releasing versions with the fixes in it. And people around the world email me on occasion--I get like 1 or 2 emails a week. Some of them have patches for things that are broken. Some of them have feature requests. One of them said he didn't like Lyntin at all. But all of them were "Thanks--great job!"
That's so cool.
Coding for me is a craft. I feel that I am a craftsman. My tools and design are intricate pieces in a harmony--a zenning out (to quote Tom Christiansen)--that touches my soul. The design, the creation, then I breathe life into my work. The sweet aromas of the debugging cycle where you become intimately aware of the inner workings. The subtle details.
This is programming as a craft. It is different from programming as a method of deriving income. For a lucky few these two can be entwined. But often the act of working as part of a development team for a client against a deadline creates an atmosphere where the creation of beauty must take a back seat for the purposes of teamwork and responsibility and producing a product that meets the customers' often haphazard and contrary-minded expectations.
But this is ok. This is as it was in the days of yore when the blacksmith would shoe your horses, then spend hours by his anvil doing intricate ironwork for gates and statues.
To keep yourself in the tao, don't be frustrated when you can't coax the beauty in every thing you do. Some things have beauty and some have functionality, and some are a total bs hack you did when you were drunk and it was late and the deadline was yesterday and you're just hoping that it doesn't cause your computer to crash before you can fully compile and check the new code in.
Update 12/9/2004: Everyone goes through a "I'm a craftsman programmer" phase as well. Well, probably not _everyone_, but a lot of programmers do. Enough that it's very clear that it's a phase/fad. Still, I think the concept of treating one's programming as a craft with the intention of doing it well rather than just doing it is probably a good thing.
Tom Christiansen wrote an article thingy about efficiency of keyboards as an input device and how it sucks. The reason for suckage is that since keyboards differ from each other, and often were designed under premises that functionality and efficiency should take a backseat to making the Enter key bigger and the space bar smaller. It's a good article. Anyhow, it talks about zenning out whilst programming. The layers between your thinking about your code, translating that into design, translating that design into functions and code, translating that into a series of instructions that you send your fingers which then type a bunch of stuff in... All that collapses into your mind and your design.
Frequently in science fiction there will be some dude with a set of vr goggles on and special gloves and they will manipulate virtual objects as if the objects were really in the space in front of the dude. It's kind of cheesy. But that's how zenning out feels. You lose track of your environment and time. Your senses fall asleep as you manipulate this virtual design in your mind of how your program works. As you manipulate it, it grows and reacts. You forget that you're typing on a keyboard. You forget to blink to keep your eyes moist.
I forget to eat and often that my body needs maintenance. This is zenning out. Then suddenly you wake up and your systems come back online and you become aware again of the world around you and your eyes hurt and you're starving and your cup of coffee has been ice cold and half full for hours.
And that is bliss. And it's even cooler when I understand what I've just written and doubly-cooler if it works.
All contents Copyright 1996 to 2010 Will Guaraldi Kahn-Greene.
This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.