On Mon, 17 Jan 2000, George Greer wrote:
> When bugs.circlemud.org/bugs is empty.
It'd help if some of the things that aren't really bug reports, are no
longer relevant, or just flat aren't true were removed... :)
Here's what I think is appropriate:
* 'docs' - clean it out, maybe take the special procedure section
for coding.doc?
* 'code' - See below for notes on bug report #5. #30, #74, #191,
#229, #238, and #270 can all be tossed. #225, #226, and #227 are
all related to the stupidity of load_zones(), which needs to be
rewritten (it isn't even re-entrant which, admittedly, isn't a
present concern, but it's still just as stupid a function as
process_output()). #251, #253, and #257 stay, since I haven't
verified them. I don't know what #262 is about, but it's not a
bug report. I'm unable to duplicate #264 and #265, but that
doesn't mean they're not really there. <Shrug>
* 'pending' - say good-bye to the 4 (not 5, oddly) reports there.
* 'incoming' - #297 is not a bug report and mainly concerns the
lack of the etext system and CircleMUD returning players to the
temple -- toss it. #298 is trash; #299 should be tossed (the
correct behavior, IMHO, is to crash when send_to_char() is called
with ch=NULL). I'll fix the typo from #300 in CVS. Dunno about
#301. Weird historical thing. #302 and #303 are really design
problems and not major issues, but I'll try to think something up
that isn't too terribly ugly. #307, #308, #309 can be discarded.
I've been unable to duplicate #310, "MAJOR BUG," reported by Bob
Castillo today on bpl16; haven't tried with CVS.
* 'windows' - not a bug report, toss it.
In 'code', #5 is a design problem. The best way to fix it is to remove
the get_obj_in_list_vis() checks from get_obj_vis() -- they cause
problems, anyway (such as cases where "stat obj 1.ring" and "stat obj
2.ring" will refer to the same instance of the same object). We can leave
this peculiar behavior in for when do_stat() is not called with an
argument. Otherwise, scan the entire list ONLY. Anything else causes
problems.
So what's that leave left? A half-dozen or so things to look into?
> I really want the independence although I think C99 (they just missed
> C00) would be better to use than ANSI C.
...err, as soon as a compiler and library fully support it. Of course, I
don't think we'll need all of the features, really. But having correct
inlines, restricted pointers, designated initialisers, control statement
variable declaration, and // comments is, I guess, worth the wait... :\
> Strangely enough, we can have "real" threads or "fake" threads as
> well. Using sigsetjmp() like in the PTH threads can get us the
> appearence of multi-threading without the system impact of actually
> having that many threads. We may prefer to have "real" threads, but
> it's an interesting option especially when you think of newbie coders
> and race conditions between threads.
Of course, you can create just as many problems with asynchronous signals
and non-reentrant functions as you can with threads and non-reentrant
functions. Maybe assuring atomic operations is easy with "fake" threads,
though, since you have much more fine-grained control over the "threads".
> And splitting the network accepting to a separate process to prevent
> crashing problems with disconnect.
I'm not sure what you mean.
> Perhaps also splitting the world out so it doesn't need to reboot in
> case of a game crash. Databases such as SQL would give that for free.
Nod. I've been thinking quite heavily along the lines of external
databases. I'm not sure if even MySQL, fastest of the fast, is exactly
ideal, but at the same time, neither are flat text files or writing our
own database code for tiny gains in processing speed. Of course, the big
problem is people who don't have SQL access in most situations, such as
Windows users. I suspect most UNIX-based Mud provider services have MySQL
already running for its users or are willing to run it for their users.
-dak
+------------------------------------------------------------+
| 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 : 04/10/01 PDT