From: fontenot@ravl.rice.edu (Dwayne Jacques Fontenot)
Newsgroups: rec.games.mud.lp
Subject: Re: MudOS a ripoff?
Date: 27 Aug 92 09:11:30 GMT
Organization: Rice University

In article <mmcg.714900981@bruce.cs.monash.edu.au> mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:
>fontenot@ravl.rice.edu (Dwayne Jacques Fontenot) writes:
>
>>In article <geoff.714882644@bruce.cs.monash.edu.au> geoff@cs.monash.edu.au (Geoff Wong) writes:
>>>
>>>Wow! - Hours of hard work and a complete re-writing; obviously.
>
>>Why are you immediately being belligerent?
>
>Yes, dear, we understand how proud you are of your little
>accomplishments and all.  You _will_ have to excuse us if
>we chortle at the way you get all snotty and defensive when
>it is suggested that some minor driver work is cause for
>a name change...

hmmm...I think you left out a "not" in the sentence above. And I chortle
at the snottiness and defensiveness...but not my own.

>>>>A completely rewritten eval_instruction (it uses pointers to functions
>>>>  instead of the large switch())
>>>
>>>Yawn - I did that 18 months ago. It's irrelevant anyway - a good
>>>compiler (gcc 2.0+) will do the job automatically anyway. Simply makes
>>>the code easier to work on.
>
>>Good for you. Did you release it? I have not seen it.
>>Guess what? Not everybody has gcc 2.0+, or a good compiler even. I am sure
>>you do...once again, good for you.
>
>Sure we do.  But we don't use it.  And, yeah, geoff posted about what
>he'd done.  Only a couple of people asked for patches.  Of course, it's
>not much use posting patches - noone uses 2.3 any more anyway...

yeh...you guys are constantly posting about what you've done. And sometimes
you posted snippets of code, along with warnings like "of course, *snicker*,
this code won't work with *your* driver unless you do the following list of
modifications, which we will not fully explain, nor tell you how to do, nor
give you code for".

I know you know that I have the articles saved. And you wouldn't want to
deny it (the above) anyway.

>>"Simply makes the code easier to work on"...simply. Can't have that, can
>>we? Ho Hum.
>
>If it's so special to you, you should have done it long ago.

Maybe we should have. But we've done it *now*. And we'll release a *complete*
driver that includes this code.

>>>>Our own version of mappings, mainly snagged from Perl
>>>>Wrappers around malloc(), realloc(), and free() which allow keeping
>>>>  track of memory (for a small overhead)
>>>
>>>Hot stuff! Catching up with the Joneses.
>
>>Have the Joneses released their code? I have not seen the malloc stuff
>>in another released driver. And some mappings are better than others.
>
>You and your fixation with releasing code.

You and your fixation with not releasing (complete, working) code, and
proceding to lord it over the beleagered readers of the lp groups.

>Does speeding up the
>mapping operation warrant a name change?  Was it TMI that designed
>the basic game structure, the way commands are added to objects,
>the way objects call each other?  Shit, did you even write your
>own compiler?

no, no, no, no, no.

>Noooooooo...

exactly.

>>>>When the name changed to MudOS, I was of the opinion that it was a
>>>>bit premature.  As things stand now, though, I think it is undoubtedly
>>>>a wholly different driver. 
>>>
>>>I doubt it - still uses the same string hashing, same backend, 
>>>same chained hash tables for objects etc.
>
>>If you are referring to 0.8.14, then you are correct...but 0.8.52 is
>>quite a different beast. Quite different indeed. If you are really
>>interested (which you, Mr. Wong are not) come to TMI and read the
>>ChangeLog, or wait for the release announcement.
>
>Changelog?  CHANGELOG?
>
>You mean you CHANGED its NAME but you are still using the SAME BASE CODE?

well...one of the entries in the changelog is:
        * added in major changes to the driver: comm1.c was almost entirely
          rewritten (again), including add_message() which is now varargs.
          The driver now implements an event queue -- this is a major change
          to the way the driver handles events/interrupts.
	  (comm1.c {now comm.c -- we changed the name!) was completely
	   rewritten to use asynchronous sockets, as was the backend loop)

Now, I know what you're going to say:

1) You had already done this before I was born.
2) It only took you 2 seconds of coding time -- with debugging.
3) You decided you liked the old way better.

>Arrogance.

Exactly.

>Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.edu.au