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:

So now the following examples are all valid variables:

• $foo
• $foo::bar
• $foo::bar(1, 2, 3)
• $foo::bar::bar2({"arg1": 1, "arg2": 2})
• $foo("arg1", 1, {"foo": "bar"})
• ...

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.

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).

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.

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.

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?

I'm going to be doing some pretty dicey pyblosxom changes over the next day. This web-site is liable to go up and down faster than a pogo stick!

You might be greeted with bugs! Stack traces smeared in pink and colors repugnant to the human eye! Strange hexidecimal incantations that look more like inscriptions to a mystical Egyptian pyramid of Ra than meaningful web-site error data! Be wary! BE VERY WARY!

Don't fret--it'll all be over in a few days. And definitely don't email me because I already know.

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

   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

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:

• new scheduler system with the ability to schedule commands to kick off at a given time
• redid the #import stuff so it's now #load and #unload
• refactoring of the thread manager, the datagrep buffer, the ticker (now uses the brand new scheduler), and session shutdown
• fixed the EOR issue, #textin, #config
• added the #grep command and removed #datagrep and #datagreplines
• implemented the #bell command and added bell functionality to the textui

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.