Feature freeze current trunk and do a code audit?

[Cozzie]

current trunk should be feature frozen so there are not many major differences between this and new AI. Along the way, a code audit should be done on openkore to just generally optimize it. When or how it should be done in conjunction with the new AI I dont know. Opinions?

[sli]

It's absolutely abysmal in practice to merge even just patches into the working branch while refactoring in another, not to mention full on features. Are bug fixes even being considered for application in the experimental AI branch or are we going to end up with a shiny new AI full of 6-8 month old bugs? Sure, you could merge the branches, but there is still keeping up that needs to be done because the experimental branch is actually functional.

And Cozzie has a good point about a code audit. At the moment, NYTProf will not run on OpenKore. That's a huge problem considering NYTProf is THE profiler to use.

And then there's this:

Code: Select all

import gettext
gettext.bindtextdomain('Erok','.\core\po')
self.T = gettext.gettext

That's the entire OpenKore translation engine (Erok's T has both T and TF's abilities through standard Python string formatting) implemented in a whole three lines in Python. I didn't even make a separate module for translations. It is absolutely infeasible that it can't be this quick and easy in Perl and it leads me to believe that OpenKore is slowly turning into festering bloatware. It's true that OpenKore works with a lot of data. But 40 megs of memory? And how much CPU time??

Honestly, OpenKore could do without a lot of the code. Erok's current code model is incredibly experimental, but as I was telling Cozzie, I plan to create an incredibly open ended bot. It's going to have plugins, of course, but it will also have...

Extensions
Extensions, unlike plugins, will not add new functionality to the bot (well, they can, but shouldn't). This will allow users and developers to add new code trivially. But for specific purpose: serverTypes, encryption, and things like that. There's going to be a separate repository for serverTypes, instead of mucking up the core repo with out-dated ones.

And what's going to make this all work? Quality control. The magic little corporate buzz word that's actually a good thing. OpenKore lacks quality control and the project has suffered substantially since its inception. While I'd love to help fix this glaring little issue that awaits in the background to rot the project from the inside, I highly doubt anyone but me and Cozzie have such a grim outlook on the project. But I do just speak for myself, maybe Cozzie doesn't feel the same.

The problem is that the rest of the other devs aren't very receptive to changes. If anyone needs a good example, just see this post (and kLab's reply), and this feature that I suggested months and months ago that got shot down. I almost feel dirty suggesting it because of the horrendously bloated model that kLab has outlined. What are we, enterprise programmers getting paid by the line?

By the time that thread was posted, I'd already implemented in a MUCH better and faster form in Erok. Enjoy your SQL queries, I prefer my method of persistent database access through a dictionary (that's what we Pythonistas call hashes and associative arrays). Basically, as far as the Erok core knows, nothing is any different if the database is being used or if the flat files are being used. It's 100% completely transparent and it's that God damn awesome.

So while I don't mind moderating the forums (and everyone knows the forums need moderation), I'm hereby no longer an active developer for OpenKore. While I could probably fix all the code that's just dripping with inefficiency, I'd rather devote my time to working on Erok so I can be sure it will Just Work(tm) from the start. It's up to you guys to decide whether or not to revoke my SVN access, but chances are that more than likely it will simply go unused.