Pages (8): 1 2 3 »
Yay for updates.
It may only have been about a week since the last update, but a fair few changes have been made since then. Here's a quick run-down on what we've been doing.
The most important change that's come about recently is the configuration file parser. Ezri can now finally read in and rehash data from a configuration file (ezri.conf), that modules can use. The configuration file API isn't complete or final, but it works, and we're already using it in the more important places. The main usage right now is that Ezri will connect to servers based on ezri.conf, rather than hard-coded values. Undoubtably a major step forward.
One of the more subtle changes is in the way we handle connections in Ezri. Before, we'd simply pass it the hostname, return a socket, and discard it, because we knew what those values were, but the changes in the configuration file have forced us to re-evaluate that slightly. We now return a struct that contains additional information such as the number of bytes sent and received, and can therefore determine data such as the average rate of transfer.
It's also possible that as a side effect of the new networking code, we've introduced IPv6 support to some systems. Whether this is true or not, I have no idea (I don't currently use IPv6), but eventually we'll test this and get it working.
Unrelated to these changes, but still important, is that the services will now synch much, much faster than before. This change is actually simple, and may yet become something better, but the simple change will stop it from timing out on a network of just about any size.
Plenty of things still to come, but that's what we've been working on.
It may only have been about a week since the last update, but a fair few changes have been made since then. Here's a quick run-down on what we've been doing.
The most important change that's come about recently is the configuration file parser. Ezri can now finally read in and rehash data from a configuration file (ezri.conf), that modules can use. The configuration file API isn't complete or final, but it works, and we're already using it in the more important places. The main usage right now is that Ezri will connect to servers based on ezri.conf, rather than hard-coded values. Undoubtably a major step forward.
One of the more subtle changes is in the way we handle connections in Ezri. Before, we'd simply pass it the hostname, return a socket, and discard it, because we knew what those values were, but the changes in the configuration file have forced us to re-evaluate that slightly. We now return a struct that contains additional information such as the number of bytes sent and received, and can therefore determine data such as the average rate of transfer.
It's also possible that as a side effect of the new networking code, we've introduced IPv6 support to some systems. Whether this is true or not, I have no idea (I don't currently use IPv6), but eventually we'll test this and get it working.
Unrelated to these changes, but still important, is that the services will now synch much, much faster than before. This change is actually simple, and may yet become something better, but the simple change will stop it from timing out on a network of just about any size.
Plenty of things still to come, but that's what we've been working on.
Lulolwen is a tardbukkit
I love updates, they give me something to read and not fully understand when I'm bored.
Good job Sheep and the guize.
Good job Sheep and the guize.
What in the devil is a snippet.
err.. oh shit what did I do.
Snippety Snippety Snippety Snip
err.. oh shit what did I do.
Snippety Snippety Snippety Snip
It's been long enough for a status report on Ezri IRC Services.
We've expanded the configuration options to allow for fully configurable services clients from the configuration file. You can now set the ident, hostname, etc for each client as an "svsclient" block, meaning that we're no longer hard coding any values into the core. Each svsclient block is a different client, with optional and required settings. One of the more interesting is the "trigger" option, explained below:
Triggers are simply the command trigger used to wake up the services client and tell it to run a command. These aren't needed in private messages, because ChanServ, NickServ etc know exactly who the recipient is, but in channels, you may prefer to use !command, or !#channel command to refer to another channel (From previous functionality). These normally aren't interesting, except that we've implemented "forwarding". If enabled in the configuration, which it is by default, ChanServ will receive the message and - If it's not destined for itself - See if it's meant for any of the other clients, such as OperServ. Since these clients don't join channels, they'd normally be unable to receive these messages, making "triggers" useless for anything that wasn't ChanServ (or the HelpServ module). Note that these are implemented in the services routine, not the core, though this shouldn't be an issue (There's no point in putting it in a devnull routine, for example).
The "access" and "register" commands now have their own configuration settings to determine which commands should be loaded at launch. The core has been updated to understand "invite" commands, and as a result of this you may now register a channel by inviting ChanServ to it. This is a neat little way to intuitively register a channel. This actually uncovered a possible bug in 3.2.8 which changed the way that "tokens" (See earlier post) are handled, but nothing exciting.
A couple of woefully-stupid bugs were fixed. Adding two events would overwrite the first, and then itself, which wasn't exactly what we had in mind. There was full support for /part in the IRCd, but it'd disappeared in one of the past revisions, it turned out that ChanServ would message a user in a channel whether they were entering a command or not, and modes set without a parameter (such as +m) would result in a crash.
Additionally, support for kicks has been added, support for quit is to be improved. Channel "limits" are now explicitly supported, along with the stored channel password, as opposed to the registered channel lock password. There's now a ChanServ invite command to invite yourself back to a channel, so not everything is core changes this time... Just most of it. ;)
We've expanded the configuration options to allow for fully configurable services clients from the configuration file. You can now set the ident, hostname, etc for each client as an "svsclient" block, meaning that we're no longer hard coding any values into the core. Each svsclient block is a different client, with optional and required settings. One of the more interesting is the "trigger" option, explained below:
Triggers are simply the command trigger used to wake up the services client and tell it to run a command. These aren't needed in private messages, because ChanServ, NickServ etc know exactly who the recipient is, but in channels, you may prefer to use !command, or !#channel command to refer to another channel (From previous functionality). These normally aren't interesting, except that we've implemented "forwarding". If enabled in the configuration, which it is by default, ChanServ will receive the message and - If it's not destined for itself - See if it's meant for any of the other clients, such as OperServ. Since these clients don't join channels, they'd normally be unable to receive these messages, making "triggers" useless for anything that wasn't ChanServ (or the HelpServ module). Note that these are implemented in the services routine, not the core, though this shouldn't be an issue (There's no point in putting it in a devnull routine, for example).
The "access" and "register" commands now have their own configuration settings to determine which commands should be loaded at launch. The core has been updated to understand "invite" commands, and as a result of this you may now register a channel by inviting ChanServ to it. This is a neat little way to intuitively register a channel. This actually uncovered a possible bug in 3.2.8 which changed the way that "tokens" (See earlier post) are handled, but nothing exciting.
A couple of woefully-stupid bugs were fixed. Adding two events would overwrite the first, and then itself, which wasn't exactly what we had in mind. There was full support for /part in the IRCd, but it'd disappeared in one of the past revisions, it turned out that ChanServ would message a user in a channel whether they were entering a command or not, and modes set without a parameter (such as +m) would result in a crash.
Additionally, support for kicks has been added, support for quit is to be improved. Channel "limits" are now explicitly supported, along with the stored channel password, as opposed to the registered channel lock password. There's now a ChanServ invite command to invite yourself back to a channel, so not everything is core changes this time... Just most of it. ;)
Lulolwen is a tardbukkit
Another update.
I haven't been able to do much work in the past two weeks due to not being around as much, but I've still managed to put in enough changes to make it newsworthy.
This time, it's been mainly bugfixes. There were several modules that had become outdated due to the changes to the core over time. One of these, OS_Umode, has been merged with the regular mode command to make things easier for the user. The say command has been rewritten again, and has an additional change - IRCops who wish to target a user with the say command must prefix the user with -. This is pretty much required so that it knows what to do with a message.
The access command has been improved with double the features. For each status command (voice, halfop etc) it provides, it'll now also provide the relevant command to remove status from the user (devoice, dehalfop etc). Related to access, you can now change the default levels settings from the configuration file, using the ChanServ::Levels block.
One of the more important changes is that an extension can now be unloaded, either by name or by filename. It'll call extension_unload to do any cleanup the module defines, and then unload it from memory. This will also happen if a module fails to load, or refuses to load due to invalid environment parameters (Such as missing services clients, configuration settings etc).
There are some bug fixes that almost seem like features, such as modes that Ezri sends now being recorded internally, wheras before they were just sent and it was assumed that the extension author would change the internal state themselves. The way configuration blocks are fetched was changed slightly due to a bug that stopped nested blocks from being properly loaded. A malformed nickname introduction could previously crash Ezri (Not protocol specific). Additionally some stupid errors were fixed - A buffer overrun and a couple of memory leaks.
So what's next? That file API would be nice, but I don't expect it to be complete anytime soon. Next will probably be the addition of ban commands, and a help command. If there's time, perhaps I'll squeeze a few OperServ commands in there, since it'll look a bit empty compared to the other clients. Then again, maybe not.
I haven't been able to do much work in the past two weeks due to not being around as much, but I've still managed to put in enough changes to make it newsworthy.
This time, it's been mainly bugfixes. There were several modules that had become outdated due to the changes to the core over time. One of these, OS_Umode, has been merged with the regular mode command to make things easier for the user. The say command has been rewritten again, and has an additional change - IRCops who wish to target a user with the say command must prefix the user with -. This is pretty much required so that it knows what to do with a message.
The access command has been improved with double the features. For each status command (voice, halfop etc) it provides, it'll now also provide the relevant command to remove status from the user (devoice, dehalfop etc). Related to access, you can now change the default levels settings from the configuration file, using the ChanServ::Levels block.
One of the more important changes is that an extension can now be unloaded, either by name or by filename. It'll call extension_unload to do any cleanup the module defines, and then unload it from memory. This will also happen if a module fails to load, or refuses to load due to invalid environment parameters (Such as missing services clients, configuration settings etc).
There are some bug fixes that almost seem like features, such as modes that Ezri sends now being recorded internally, wheras before they were just sent and it was assumed that the extension author would change the internal state themselves. The way configuration blocks are fetched was changed slightly due to a bug that stopped nested blocks from being properly loaded. A malformed nickname introduction could previously crash Ezri (Not protocol specific). Additionally some stupid errors were fixed - A buffer overrun and a couple of memory leaks.
So what's next? That file API would be nice, but I don't expect it to be complete anytime soon. Next will probably be the addition of ban commands, and a help command. If there's time, perhaps I'll squeeze a few OperServ commands in there, since it'll look a bit empty compared to the other clients. Then again, maybe not.
Lulolwen is a tardbukkit
A few weeks on, and enough changes have been made for an update. There are definitely some things to note this time, but I'll start with the smaller stuff.
First off, we made a lot of the string-handling functions faster. There was no reason to allocate memory half of the time, so we stopped doing that. strtolower/strtoupper now modify the string they were given, but this isn't an issue (The only time this would matter is when you were comparing case, see case_compare to do that). We also made case-insensitive (case_compare) almost as fast as regular comparison, so the overhead is back to being negligible.
There are several new commands to use with Ezri now. I guess that when the core becomes usable, this kind of thing starts to happen. The core is hardly final, but it's a lot more final than it used to be. The result being that we have a "kill" command attached to OperServ to disconnect users from the network, we fixed the "rehash" command, the "setting" command for getting configuration settings is now available, and we finally brought back the "help" command to provide extension help.
A fair few potential crashes were fixed. You can now add commands to all clients of a given "type", which is something that's been needed for some time. Same applies to the help, for obvious reasons. You can now return a configuration "block" through the config API, which could save a lot of lookups if you have a particularly large block. The "say" command was again modified so that only IRCops could "say" via clients that weren't of a ChanServ type.
There are plenty more changes, of course, but those are some of the more notable ones. I did say that there was something worth mentioning though, so...
Ezri has database support.
I didn't think I'd see the day when I wrote that, but it's been realised. Ezri now has a db_simple extension which allows it to read and write the most simple format we could come up with that wouldn't become a problem. Currently, nicknames, channels and the HostServ module use it. We'll be adding in the channel levels and access levels later, so it's still not "ready", but it works, and that's important.
So obviously we have a lot left to do, but we have a lot less to do. We might even meet our target of having a release this year. Who'd have thought?
First off, we made a lot of the string-handling functions faster. There was no reason to allocate memory half of the time, so we stopped doing that. strtolower/strtoupper now modify the string they were given, but this isn't an issue (The only time this would matter is when you were comparing case, see case_compare to do that). We also made case-insensitive (case_compare) almost as fast as regular comparison, so the overhead is back to being negligible.
There are several new commands to use with Ezri now. I guess that when the core becomes usable, this kind of thing starts to happen. The core is hardly final, but it's a lot more final than it used to be. The result being that we have a "kill" command attached to OperServ to disconnect users from the network, we fixed the "rehash" command, the "setting" command for getting configuration settings is now available, and we finally brought back the "help" command to provide extension help.
A fair few potential crashes were fixed. You can now add commands to all clients of a given "type", which is something that's been needed for some time. Same applies to the help, for obvious reasons. You can now return a configuration "block" through the config API, which could save a lot of lookups if you have a particularly large block. The "say" command was again modified so that only IRCops could "say" via clients that weren't of a ChanServ type.
There are plenty more changes, of course, but those are some of the more notable ones. I did say that there was something worth mentioning though, so...
Ezri has database support.
I didn't think I'd see the day when I wrote that, but it's been realised. Ezri now has a db_simple extension which allows it to read and write the most simple format we could come up with that wouldn't become a problem. Currently, nicknames, channels and the HostServ module use it. We'll be adding in the channel levels and access levels later, so it's still not "ready", but it works, and that's important.
So obviously we have a lot left to do, but we have a lot less to do. We might even meet our target of having a release this year. Who'd have thought?
Lulolwen is a tardbukkit
I think it's about time for another update. We've certainly done enough to make this one notable.
One of the focuses of the last two weeks has been all about speed. There are two operations that are normally considered "Expensive" on most platforms - Allocating memory, and file handling. Knowing this, we've taken the time to vastly reduce the amount of times that either are used. The result of this is evident with several new string functions making their debut appearence. Additionally, many of the string functions which were already in place have received tweaks, a couple have been outright removed in favour of native (Usually more optimised) string functions. The result is a faster experience on large networks, perhaps as much as 5% in regular operation and 10% during synch, but these are guessed figures, and things were already pretty fast from the last round of fixes.
Another new string function is a banmask creator. This isn't too exciting, but highly useful. It takes input and creates a banmask of the form *!*@* no matter which pieces it's given. Not too fascinating, but needed for the feature additions.
Ezri can now track bans. This is another of those things that have been a long time in the coming, and most of the code was probably in the core already, but it's done now. Bans, excepts, and invexes are properly handled by the services, including UnrealIRCd "extended" bans such as mutes. UnrealIRCd "ban all in #channel" bans are not yet supported, and may not be supported, depending on how wanted a feature to emulate its functionality is.
Relatedly, there's a new "BAN" command added to ChanServ-type clients, which will - Perhaps unsurprisingly - Ban a user from the channel. This is actually still in development as I write this, but the "BAN" command works. Others such as "UNBAN" and a couple of other related commands will be implemented by the end of the day (Props to good engineering? Perhaps, but it's the case).
To complement BAN, there's also a "KICK" command and access level to complement it. It'll simply kick a user from the channel with the given reason. Everyone knows what a kick command is, so there's no real need to explain how these commands work.
A number of stupid bugs in the e-mail validator were fixed. Previously, it would consider .@a to be a valid e-mail address. I don't, and I don't think anyone else does either. We re-ordered parsing in the Unreal extension to give performance boosts on every received token (Tokens further down the list will receive biggest boosts), we added some orphaned code for "SERVER" support, along with proper understanding of NS/VL tokens, and fixed a completely missed crash which would cause Ezri to crash if it was unable to connect to the IRCd.
There are plenty of minor changes among them, a missed memory leak in OperServ-type KILL would have been fixed in the round of fixes for the next two weeks, but we decided to catch it now while it was known, support for CTCPs and CTCP events are enabled for the default routine, and the process_message function has been reworked to stop assuming the format a server sends PRIVMSG with.
As for the stupid bug fixes this time round, we've had a couple to work with. In fact, I had to fix one twice. You can no longer re-register the most recently registered nickname (This isn't a security issue, the /second/ name could never be logged into, not the first), fixed plenty of bugs relating to memory management when importing nicknames and channels, not to mention a few potential crashbugs. There was a crash if an impossible PART message was received by the server, so naturally we didn't actually trigger this one. We'd also managed to introduce a bug where it would crash if you didn't have sufficient permissions to use the command, but that's also fixed.
All in all, one of the more feature-packed announcements. I suspect I'll be bumping the internal version with the next announcement, which might be a call for beta testing.
One of the focuses of the last two weeks has been all about speed. There are two operations that are normally considered "Expensive" on most platforms - Allocating memory, and file handling. Knowing this, we've taken the time to vastly reduce the amount of times that either are used. The result of this is evident with several new string functions making their debut appearence. Additionally, many of the string functions which were already in place have received tweaks, a couple have been outright removed in favour of native (Usually more optimised) string functions. The result is a faster experience on large networks, perhaps as much as 5% in regular operation and 10% during synch, but these are guessed figures, and things were already pretty fast from the last round of fixes.
Another new string function is a banmask creator. This isn't too exciting, but highly useful. It takes input and creates a banmask of the form *!*@* no matter which pieces it's given. Not too fascinating, but needed for the feature additions.
Ezri can now track bans. This is another of those things that have been a long time in the coming, and most of the code was probably in the core already, but it's done now. Bans, excepts, and invexes are properly handled by the services, including UnrealIRCd "extended" bans such as mutes. UnrealIRCd "ban all in #channel" bans are not yet supported, and may not be supported, depending on how wanted a feature to emulate its functionality is.
Relatedly, there's a new "BAN" command added to ChanServ-type clients, which will - Perhaps unsurprisingly - Ban a user from the channel. This is actually still in development as I write this, but the "BAN" command works. Others such as "UNBAN" and a couple of other related commands will be implemented by the end of the day (Props to good engineering? Perhaps, but it's the case).
To complement BAN, there's also a "KICK" command and access level to complement it. It'll simply kick a user from the channel with the given reason. Everyone knows what a kick command is, so there's no real need to explain how these commands work.
A number of stupid bugs in the e-mail validator were fixed. Previously, it would consider .@a to be a valid e-mail address. I don't, and I don't think anyone else does either. We re-ordered parsing in the Unreal extension to give performance boosts on every received token (Tokens further down the list will receive biggest boosts), we added some orphaned code for "SERVER" support, along with proper understanding of NS/VL tokens, and fixed a completely missed crash which would cause Ezri to crash if it was unable to connect to the IRCd.
There are plenty of minor changes among them, a missed memory leak in OperServ-type KILL would have been fixed in the round of fixes for the next two weeks, but we decided to catch it now while it was known, support for CTCPs and CTCP events are enabled for the default routine, and the process_message function has been reworked to stop assuming the format a server sends PRIVMSG with.
As for the stupid bug fixes this time round, we've had a couple to work with. In fact, I had to fix one twice. You can no longer re-register the most recently registered nickname (This isn't a security issue, the /second/ name could never be logged into, not the first), fixed plenty of bugs relating to memory management when importing nicknames and channels, not to mention a few potential crashbugs. There was a crash if an impossible PART message was received by the server, so naturally we didn't actually trigger this one. We'd also managed to introduce a bug where it would crash if you didn't have sufficient permissions to use the command, but that's also fixed.
All in all, one of the more feature-packed announcements. I suspect I'll be bumping the internal version with the next announcement, which might be a call for beta testing.
Lulolwen is a tardbukkit
I elected to delay the last announcement for two weeks as I was unable to work on Ezri for at least a week due to minor surgery with lasting effects, but now that four weeks has passed, I can tell you what's changed.
There was a surprising bug caught due to the way sockets worked. It turns out that when we rewrote the socket code, we set things up so that timers would never fire. Whilst this would indeed speed things up, it wasn't the kind of optimisation we had in mind. Timers work again, though not in a way I'd like them to. They'll fix themselves in the future, however, as the socket code needs at least one more rework.
How do you catch timer code? By adding timers. Why would we add timers? Because we now have a TBAN command which will ban a user from a channel for N seconds, then unban. This fixes many cheap solutions with people using mIRC scripts to achieve the same thing in other packages, something which can only be a good thing.
As well as making timers much more usable from a developer perspective, a few fixes were made to the Unreal module, the SJOIN parser was slightly wrong, that's been corrected. Our capability detector was also wrong, and we've corrected that too. Minor bandwidth improvements were made by tokenising the commands we send where possible, which we were already doing for the most part. Some fixes were made to the "simple" database driver to stop a potential double free from occurring.
A few of the functions that we plan to use in extensions in the future were not being exposed properly, and we've managed to further reduce compilation time by re-ordering our includes such that no header is included twice in the project, something we thought was already the case. gcc, however, told us otherwise.
Yes, Ezri now compiles and runs with gcc.
After two days and much screaming at ISO C Standards violations POSIX wanted us to do, along with the lack of a decent IDE (Please, recommend me one that isn't KDevelop, Dev-C++, Eclipse or Code::Blocks), the dev net is currently running and stable on x86_64 Linux. gcc was able to tell us a few things that VS2005 wasn't, and vice versa, resulting in an improved and truly cross-platform Ezri codebase. Having ezri fail at every step along the way also allowed us to catch and handle possible errors, and many crashes have been fixed as a result. Ezri will no longer crash if you've not included the configuration file. Ezri will tell you exactly which file it couldn't load. Ezri now follows Sheep's Three Rules Of Source:
1. If it didn't work, tell me what I need to do.
2. If you can't tell me what I need to do, tell me why it failed, and not in machinespeak.
3. If you can't tell me why it failed, tell me exactly how I might find out.
We're obviously using a pretty recent version of gcc, but assuming the flags didn't change, there's no reason that it wouldn't work with much earlier versions of gcc. As far as I know, we aren't using any aspects of C99 in Ezri, which guarantees compilation on most compilers ever released.
Now that we can bump the version to 0.7, we can increase the rate at which we add features. It also means that I can go back to an OS that's ready for the desktop.
There was a surprising bug caught due to the way sockets worked. It turns out that when we rewrote the socket code, we set things up so that timers would never fire. Whilst this would indeed speed things up, it wasn't the kind of optimisation we had in mind. Timers work again, though not in a way I'd like them to. They'll fix themselves in the future, however, as the socket code needs at least one more rework.
How do you catch timer code? By adding timers. Why would we add timers? Because we now have a TBAN command which will ban a user from a channel for N seconds, then unban. This fixes many cheap solutions with people using mIRC scripts to achieve the same thing in other packages, something which can only be a good thing.
As well as making timers much more usable from a developer perspective, a few fixes were made to the Unreal module, the SJOIN parser was slightly wrong, that's been corrected. Our capability detector was also wrong, and we've corrected that too. Minor bandwidth improvements were made by tokenising the commands we send where possible, which we were already doing for the most part. Some fixes were made to the "simple" database driver to stop a potential double free from occurring.
A few of the functions that we plan to use in extensions in the future were not being exposed properly, and we've managed to further reduce compilation time by re-ordering our includes such that no header is included twice in the project, something we thought was already the case. gcc, however, told us otherwise.
Yes, Ezri now compiles and runs with gcc.
After two days and much screaming at ISO C Standards violations POSIX wanted us to do, along with the lack of a decent IDE (Please, recommend me one that isn't KDevelop, Dev-C++, Eclipse or Code::Blocks), the dev net is currently running and stable on x86_64 Linux. gcc was able to tell us a few things that VS2005 wasn't, and vice versa, resulting in an improved and truly cross-platform Ezri codebase. Having ezri fail at every step along the way also allowed us to catch and handle possible errors, and many crashes have been fixed as a result. Ezri will no longer crash if you've not included the configuration file. Ezri will tell you exactly which file it couldn't load. Ezri now follows Sheep's Three Rules Of Source:
1. If it didn't work, tell me what I need to do.
2. If you can't tell me what I need to do, tell me why it failed, and not in machinespeak.
3. If you can't tell me why it failed, tell me exactly how I might find out.
We're obviously using a pretty recent version of gcc, but assuming the flags didn't change, there's no reason that it wouldn't work with much earlier versions of gcc. As far as I know, we aren't using any aspects of C99 in Ezri, which guarantees compilation on most compilers ever released.
Now that we can bump the version to 0.7, we can increase the rate at which we add features. It also means that I can go back to an OS that's ready for the desktop.
Lulolwen is a tardbukkit
I actually thought I'd written one of these already, but it seems to have been lost somewhere.
There's been some major work on the Ezri core again, and it seems like everything has seen some improvements.
For example, the extension format is now simpler than before. It'll now intelligently read in the information from the headers and fill in the extension information. The old method required you to manually initialise the extension. The new method is much, much cleaner. There are also some placeholders for improving the system further.
There have been some major and minor fixes. Some places where my own three rules were not being followed have been amended with the right information. A few rare memory leaks and crash bugs - Most of them limited only to theoretical - Have been fixed. The help system has had several internal fixes that should enable it to work better. There was also a stupid bug with hash-comments, which was uncovered in the new language core.
Ezri's language core has again written to be simple yet powerful. The initial implementation is ready, and all extensions have been rewritten to make use of it. More accurately, all of them had to be, but they're using it nonetheless. The language core will let the same extensions message the user in any installed language. It's even trivial to add more languages.
While redoing all the extensions, a few of them were improved. The ghost command no longer assumes "NickServ", the lock command checks that the user is identified, as do the HostServ-style and new MemoServ-style commands. The HostServ/MemoServ commands are still experimental, but there isn't much to call "Complete" about Ezri yet, there's a way to go before we're happy and still people want to use it. Fascinating, I guess.
I think that for now, most of the bugs have been fixed. That should mean a more feature-packed update for the next Ezri news post.
There's been some major work on the Ezri core again, and it seems like everything has seen some improvements.
For example, the extension format is now simpler than before. It'll now intelligently read in the information from the headers and fill in the extension information. The old method required you to manually initialise the extension. The new method is much, much cleaner. There are also some placeholders for improving the system further.
There have been some major and minor fixes. Some places where my own three rules were not being followed have been amended with the right information. A few rare memory leaks and crash bugs - Most of them limited only to theoretical - Have been fixed. The help system has had several internal fixes that should enable it to work better. There was also a stupid bug with hash-comments, which was uncovered in the new language core.
Ezri's language core has again written to be simple yet powerful. The initial implementation is ready, and all extensions have been rewritten to make use of it. More accurately, all of them had to be, but they're using it nonetheless. The language core will let the same extensions message the user in any installed language. It's even trivial to add more languages.
While redoing all the extensions, a few of them were improved. The ghost command no longer assumes "NickServ", the lock command checks that the user is identified, as do the HostServ-style and new MemoServ-style commands. The HostServ/MemoServ commands are still experimental, but there isn't much to call "Complete" about Ezri yet, there's a way to go before we're happy and still people want to use it. Fascinating, I guess.
I think that for now, most of the bugs have been fixed. That should mean a more feature-packed update for the next Ezri news post.
Lulolwen is a tardbukkit
http://www.assembla.com/wiki/show/ezri
Good luck