On Wed, 16 Jun 1999, Daniel A. Koepke wrote:
>Everyone is focusing on getting 3.1 out the door before we worry too much
>about final decisions for 4.0.
True, but I like to collect things on
http://www.circlemud.org/~greerga/TODO.html in the meantime.
>And there are other options that, at least, George is investigating for
>4.0.
So far I've found glib (ftp://ftp.gtk.org/pub/glib/) to be designed fairly
well. Ignoring the whole 'gpointer' and 'gint' nonsense of course. I
don't see a problem with the 'gint32' type, but I really disagree with
'gpointer' as a type. Reminds me of C++ references and how you forget when
you're working with a pointer and need '*' or not. Otherwise, it finally
gives useful structured building blocks. Re-writing a queue system for
every program does get tedious quickly.
>But, no plans are finalized and, as always, the final decision is
>Jeremy's.
Documentation is the current largest issue with the CircleMUD release.
There needs to be documentation written up and the current SGML was written
with a custom parser in mind that is no longer available.
>I don't think there's that much of a learning curve. However, the ANSI
>standards committee working on C++ appears to be trying very hard to
>make the language harder to use and look at. Point of reference: new
>style casting which use the template syntax, which was ugly and unreadable
>to begin with.
CircleMUD will always try to compile in a C++ compiler barring some stupid
incompatibilities in the language. Their 'extern' treatment borders on
that.
>It should be done in whatever language and in whatever way that Jeremy and
>George determine best suits the future of CircleMUD.
JavaScript. :)
>I am pressing for less features to be in CircleMUD -- or to make the
>standard distribution features more easily removable.
I did just that in one of my code bases. Boards, mail, shops, special
procedures, magic, skills, and a few other things were all compile-time
selected. Any number of them could be removed independently restricted
only the obvious, like shops require special procedures.
I didn't do it just to be anal about things but was the end result of
throwing "#if 0" around liberally to isolate the code required by various
subsystems that was't with what required it.
>Not everyone wants the same implementation of races, classes,
>etc., in their MUD, and such creative minds should not be punished by
>having to rip out a mountain of code.
My method of board removal was basically "remove boards.o from object list
and #ifdef what breaks." Wasn't too rough and most things were in the
right places when I did the other stuff.
>As far as bugs go, well...people don't typically release code with
>serious, obvious bugs in it.
bpl15 (and 16) currently have some real irkers. Need to find the time to
make sweeping changes to fix them.
>Nor do Jeremy or George. All of the 3.0s we've seen so far are betas
>that have been eliminating bugs.
"return (0)" notwithstanding. :)
That was a code consistency thing though.
>The next non-beta release, which is 3.1 for those keeping score at home,
>shouldn't have any bad, noticable bugs.
We could make 'version' crash, oh wait, that's been done...
>Of course, it's no trivial task to eliminate *all* the bugs...
void main(void)
{
return 0;
}
Even the above has a bug.
--
George Greer | Stock CircleMUD Bug Reporting or Help
greerga@circlemud.org | http://bugs.circlemud.org/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST