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.
[#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.
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.
Pipes are neat, because they enable filters such as translation. Some commands such as give and echo could also be seen as pipes.
Karma could use some improvements.
‘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’
so ‘seen nick’ would say “last seen …..” or “nope, never heard of them”
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.
!oh noes, !/dev/null commands which use/abuse random users
!fight weechat irssi
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
[#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.
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 -
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.
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.