Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: 76fb5c79df
Fetching contributors…

Cannot retrieve contributors at this time

140 lines (139 sloc) 7.265 kb


Listeners in Fibers

If/When CL fibers are available, we should use those for listeners in the multiprocessing version of the bot.


the fact regex fails for quotes like “thewizord is a tree”

because it reads the ‘the’ and then goes OH NOES - need to fix the regex

Proper plugin system

There should be a plugin prototype that defines an interface for all plugins to follow. It should also provide capabilities for defining and controlling things like commands and listeners on a per-plugin basis.

Listeners as sheep

This will give good modularity for the various parts of the command system, and will also make aliases easier later on.

Command system

[#A] GIVE command

This command probably requires a bit of restructuring of the way the command system works. Right now, commands assume their replies are simply going to be sent back to the original sender. GIVE breaks this, and since it’s supposed to be a command, it would probably be trapped by the system’s requirement that ‘everything is a reply’.

[#A] Admin access

Maybe later? Register users, etc.

[#B] Fix thinko with #’build-string

Get that to work as it should. Hint: output is to a stream, but maintain abstraction over IRC lib.

[#B] Aliases

Aliases are one of the features requested by wizzo, and thus are a high-priority item. They would also help with some things like the command prefix.

[#C] Pipes

Pipes are neat, because they enable filters such as translation. Some commands such as give and echo could also be seen as pipes.

[#C] Karma

Karma could use some improvements.

Other stuff

‘weather <place> <time>’

If somebody says, “I’m going camping tomorrow and I’m worried about the weather”, it should be possible to look up tomorrow’s weather and remove all doubt about the success of the trip.

‘log last five minutes and post to wiki…’


Sort out the reflection so ‘you and your family’ ‘my family and I’

seen listener

so ‘seen nick’ would say “last seen …..” or “nope, never heard of them”

Praise listener

listen for stuff like nick++ or nick ftw


Prevent it somehow. Have a system for ignoring user input for certain listeners/commands. If a users gives 5 invalid commands , 5 times the same commands ignore him for 5 minutes.

Google fight

!oh noes, !/dev/null commands which use/abuse random users

!fight weechat irssi

Stalk command

like stalk nick yawn then like a certain %age of the time after nick speaks, say yawn. (good for bruenig)


Version 0.2 will resemble 0.1 strongly, with two main exceptions:

  • There will be a better-integrated help system,
  • The bot will run in one thread entirely, with the option of forking the entire bot into a new thread for debugging ease

[#A] Bugfixes

[#B] help command fails

The help command is currently completely useless.

[#B] URL Listener fails

The URL listener is currently failing to pick up on URLs.

Persistance fails

Currently, all the persistance stuff is getting loaded after init-bot returns, thus, after it’s all been overwritten with the new data from the last chat. ie, you lose all the old data.

“<bot>: error” fails

Get proper error feedback to IRC. As a plus, make this use the condition-system for better flexibility

[#B] New Help System

This is related to fixing the “help command fails” bug.

Commands inherit from listeners

This will mean more in the future, but as far as v0.2 matters, it’ll help with the help/documentation system.

Help command uses new system

[#C] Threading Options

Single threaded execution

Running in a single thread cuts a dependancy, and enables the bot to run on a wider variety of platforms and implementations. It also just makes for a generally lighter bot.

  • Marked as TODO due to bugs; see Bugfixes -

Separate thread

On implementations and platforms that support multiprocessing, it helps to run the bot in a separate thread, so that we can interact with Lisp at the REPL to modify the bot’s behavior. We should be able to fork off the bot process if possible.


[#A] Goals for new command system

These are the requirements specified by sykopomp for the new command system to be a viable alternative to the current one.

[#A] Proper Reporting of Incorrect Syntax

This is not present in the current system, however, it is highly desired by sykopomp. This could actually just be a hook into a help system. UPDATE sykopomp: This sort of works right now, but it can grow better as the command system grows and evolves. It gives some decent enough feedback for the time being, though.

[#A] Deal correctly with bad arglists

ie, don’t send “NIL” to google search.

[#B] Conditions for command errors

Some good feedback. This also means in general a system for dealing with conditions (not just serious-error) that get caught at command-listener. UPDATE sykopomp - Feedback is fine right now. We’re catching conditions, and the conditions are output to channel. If we ever need specific conditions, we can just signal them within commands.

[#B] Simple DEFCOMMAND Macro

Sykopomp likes simple macros (who doesn’t?). Also, it should be transparent enough that if it breaks, it’ll be easy for anybody to understand and fix, regardless of who wrote it.

[#C] Compatibility with Existing Commands

The transition should be smooth. This can be worked on once there is something to transition to.

[#C] Features requested by wizzo

I guess if we actually get these features built into sykobot, it may actually replace supybot as phrik’s backend.

google search


Persistent quotegrabs, including being able to !grab, !rq, and !q <someone>


ability to define simple persistent factoids that can be called up with just !factname


Under progress, almost DONE. Make a fix that every questions works for ‘I’ and ‘i’


Don’t want this fucker crashing. UPDATE sykopomp - After that horrible day when everything crashed, the bot’s been ridiculously stable. I’m tentatively tagging this as done. There’s still plenty of work to do with stability, but I think it’s all about maturing from now on.

[#C] Other Features


Record karma points for each user, and allow giving positive and negative karma. People’s ability to give karma depends on how much karma they themselves have. UPDATE sykopomp: We can probably improve this a bit still, but it’s probably not worth much effort until 0.2. I’m tagging this as tentatively done.

!fight weechat irssi

!oh noes , !/dev/null commands wich use/abuse random users

[#C] Slap command , needs to use a seperate file for slap items

Jump to Line
Something went wrong with that request. Please try again.