FelBot!

[MyndFyre]

Top of the line efficiency? We're talking about a program that watches a socket for data indicating that people are joining/leaving/chatting in a channel. How much processing power do you really think that takes? My bot's written in java, and I've never seen a stable build spike above 2% CPU usage.

That's true enough, in this instance.  One of the things I always focused on when I was learning was learning how to do programming tasks the right way, though.  There's nothing wrong with taking the time to learn advanced optimization techniques in a project like this (though, the fundamentals are far, far more important).

Remember: your goals aren't always the same as other people's.  It's true that sometimes you *should* point out when something is going to be a waste of time and energy (god knows I do it at work a lot).  But sometimes the goal is learning for the sake of learning, and when that's the case, don't try to stand in people's way.  You've no idea what kinds of things someone will learn on even a misguided plan.  (Shoot, I learned what a Singleton object was because I was trying to learn about .NET remoting.  It made my world a different place. )

[Camel]

I absolutely believe that algorithmic efficiency is rudimentary! Warrior was not referring to algorithmic efficiency, but the efficiency of a system that has hooks for plugins versus one that does not. In a properly designed system, you should not be able to measure the difference, and I tried to make that point subtly by explaining how my bot works. In my bot, the GUI is a plugin, and has been designed as a plugin since before it had a GUI. That ensures two things: the plugin framework is feature complete, and the bot is not inherently bogged down by a GUI.

[Warrior]

I absolutely believe that algorithmic efficiency is rudimentary! Warrior was not referring to algorithmic efficiency, but the efficiency of a system that has hooks for plugins versus one that does not. In a properly designed system, you should not be able to measure the difference, and I tried to make that point subtly by explaining how my bot works. In my bot, the GUI is a plugin, and has been designed as a plugin since before it had a GUI. That ensures two things: the plugin framework is feature complete, and the bot is not inherently bogged down by a GUI.

Definitely was not my point, my point was the usability differences between a Queue specialized for heavy moderation and one specialized for Chatting. In days past the two were very distinct things, since then most flood bots have come and gone so the need has gone down and given way to a potentially more unified system. This is noted in my last sentence of my original statement.

[Camel]

In that case, remove the sentence where I mis-interpreted what you said, and the rest of my post is still spot-on. In any event, I still don't believe your point is valid, Warrior. You can simply disable the queue for 'chat mode' or have two different algorithms. This isn't a difficult concept, and I'm not sure why you would argue the point you did.

[Warrior]

In that case, remove the sentence where I mis-interpreted what you said, and the rest of my post is still spot-on. In any event, I still don't believe your point is valid, Warrior. You can simply disable the queue for 'chat mode' or have two different algorithms. This isn't a difficult concept, and I'm not sure why you would argue the point you did.

This is exactly what I suggested in my first post, it's very much possible to switch queues on-the-fly. Not really sure what's being argued.

[Camel]

I was talking about your comment regarding efficiency, secon paragraph:

I think it'd be possible with a rich plugin environment. Perhaps the ability to swap queue systems tiered more towards chat/moderation and such.

Even then, it's perfectly possible to have a somewhat decent moderation and a chat client if you're not concerned with top of the line efficiency. Not that it's much of a problem anymore though.

What I'm saying is that there's no hit to efficiency if it's properly implemented.

[Warrior]

I was talking about your comment regarding efficiency, secon paragraph:

I think it'd be possible with a rich plugin environment. Perhaps the ability to swap queue systems tiered more towards chat/moderation and such.

Even then, it's perfectly possible to have a somewhat decent moderation and a chat client if you're not concerned with top of the line efficiency. Not that it's much of a problem anymore though.

What I'm saying is that there's no hit to efficiency if it's properly implemented.

I think you misunderstood me. What I mean was it's possible to write a moderation and chat client using a unified queue with decent response speeds.

[Joe]

I'm putting a few more days of testing / fixing behind 1.03 then releasing it. Notable changes are a fix in the way I received packets (causing some to be unparsed.. bad!), rewriting the entire channel list, using anonymous methods in some places (I anticipate a bit less memory usage), and moving lockdown hashing from long-term to-do to short-term to-do, thanks to MyndFyre's new MBNCSUtil.

[Joe]

I sold out.

Most of the update information will be handled there from now on, so you all know. PLEASE, test the bejesus out of it and report any bugs you find. Also, critique my source code (which is available in the SVN) and let me know of ways I can improve. I know it's not perfect.

By the way, if you find any private information in there, please report it to me via IM/PM immediately. Thanks!

[Warrior]

Props for not using a cancerous license.

[Camel]

I use the cancerous GPLv2 because it protects the code that's out there from being totally ripped off. If someone asked me for permission to use a part of my code without the license, I'd have to have a really good reason to deny them.

@Joe: Good job choosing the best code site ever If you did manage to put personal information in SVN, it's locked in forever! It's trivial to get old revisions, even anymously, from SVN. If Google ever archives that site, it could be one search away! Be careful, and use svn:ignore on all the files you don't want checked in.

[Joe]

If anyone's interested on what's up, check this out.

http://felbot.googlecode.com/svn/trunk/Felbot/_Documentation/Changelog.htm

By the way, svn/trunk/Felbot can be checked out and run at any time. I don't think I've ever uploaded a non-building commit -- I always commit after testing stuff. Sometimes stuff is broken, but it's usually not.