Will's blog

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.

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.

Lyntin, one of the projects I spent many many hours on, is now listed in the FreeBSD ports system.

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.

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:

• fixed a couple of bugs
• optimized out the get_engine() silliness
• wheedled down the managers (there's still some more to do)
• optimized the get_current_session() routine
• optimized the filter_mapper case of hook spamming
• made some really awesome changes to the python_cmd that make it far more usable

All good stuff none of which would have happened with a quiet mailing list.

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!

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!

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:

• It would be more efficient if... (this is my personal favorite since it's almost never accompanied by any kind of explanation as to why the sender thinks it's more efficient or what conditions the existing code is inefficient in)
• You need feature x, otherwise no one will use <software>...
• It would be more user-friendly if...
• Everyone will want feature x...
• Your documentation is terrible...

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!

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:

• Added Python distutils support (will make packaging much much easier).
• Removed the Tintin eval mode and the idea of eval modes.
• Refactored hooks. Hooks now pass around arguments in dicts rather than tuples--this is a big big change from 3.x.
• Split much of Lyntin's internal configuration into the constants module and the config module.
• Wrote a completely new configuration system.
• Overhauled ui's so that they'll work correctly. This also makes it possible to write ui's in other widget systems.
• Split the substitutes module into substitutes and gags.
• Added a configuration ini file for setting boot options.
• Added tagged actions and also the ability for actions to trigger off of text with/without ansi colors removed.
• Fixed a bunch of bugs, some documentation updates (but not many), and additional features here and there (most of which aren't documented yet--sorry guys).

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.

Download here (.tar.gz).

Rock on!

Download it now!

• added #antisubstitute command
• added action priorities
• fixed #read and #write so they're inverses of each other
• changed handling of IAC GA and IAC TELOPT_EOR
• changes to documentation and help system
• fixes to Lyntin so we handle errant mud echo requests better
• added a debugmode (#config debugmod) for making macro writing easier
• cleanup to plugin importing at startup

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!

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:

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

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

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

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

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

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

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

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

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

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?

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.

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

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.

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.

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:

• figure out if command parsing needs some attention in terms of unescaping characters
• get a help file from Josh on lyntin eval mode
• build a setup.py for distutils installation
• let the code bake a bit and testing

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:

• move the ticker to its manager
• figure out if command parsing needs some attention in terms of unescaping characters
• write help files for lyntin and tintin eval modes
• uncouple hooks from hooks.py so module writers can write their own hooks
• build a setup.py for distutils installation

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.

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.