From lucid.com!yduj Tue Jan  7 22:08:08 1992
X-VM-VHeader: ("Date:" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Discarded-Parts:" "Reply-To:" "X-Filters-Matched:" "X-Annotation-.*:" "Newsgroups:" "Content-Type:" "Content-Transfer-Encoding:" "Resent-To:" "Resent-From:" "Resent-Date:") nil
X-VM-Bookmark: 445
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28302>; Tue, 7 Jan 1992 22:08:03 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12331>; Tue, 7 Jan 1992 22:07:32 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12329>; Tue, 7 Jan 1992 22:04:43 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 7 Jan 1992 22:03:03 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12322>; Tue, 7 Jan 1992 22:02:30 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <12332>; Tue, 7 Jan 1992 22:01:56 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA08732g; Tue, 7 Jan 92 21:58:25 PST
Received: by boston-harbor id AA05245g; Wed, 8 Jan 92 01:02:21 EST
X-NS-Transport-ID: 08002008D0FD00159712
Message-ID: <9201080602.AA05245@boston-harbor>
Date:	Tue, 7 Jan 1992 22:02:21 -0800
From:	Judy Anderson <yduj@lucid.com>
To:	moo-cows.PARC@xerox.com
cc:	forrie%morwyn@unhtel.unh.edu
Subject: Found on rec.games.mud

Figured this message would have a better home here...

Article 8731 of rec.games.mud:
From: forrie@morwyn.UUCP (Forrie Aldrich)
Newsgroups: rec.games.mud
Subject: LambdaMOO
Summary: Need compiling assistance.
Keywords: MOO
Message-ID: <195@morwyn.UUCP>
Date: 8 Jan 92 03:59:38 GMT
Organization: CREATIVE CONNECTIONS - Dover, NH - USA
Lines: 29

(I hope this is the right group...)

I recently acquired the src code to LambdaMOO.  I have a SysV machine,
and am running into some difficulty compiling it.  First off, the machine
I own is an AT&T 3b1 (I know, I know)... and I acquired the WIN/TCP
package as well (by the Wollongong group), which provides the sockets, etc.
BUT, I have run into some problems like 'fd_set' being undefined in the
headers and the such.  Well...

I wondered if there might be someone out there who has been able to get
around these problems, and successfully compile it as such.  I realize
that my platform may not be the best, but I can't believe that it's 
impossible at this point.  Any and all help would be greatly appreciated...

Please NOTE:  I do not get this group as a regular feed, therefore, please
respond to me via email...:

		forrie%morwyn@unhtel.unh.edu

Thanks!

-- 

--------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--------------------
Forrest Aldrich, Jr.|   (a reliable path here someday)   |forrie@morwyn.UUCP
                    |           <email paths>            | 
VISION GRAPHICS     |    morwyn!forrie@unhtel.unh.edu    |Graphic Illustration
------------------\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/------------------
                   \__________ Dover, NH  03820 __________/                   



From lucid.com!yduj Sun Jan 12 08:37:42 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28064>; Sun, 12 Jan 1992 08:37:40 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12015>; Sun, 12 Jan 1992 08:37:14 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12016>; Sun, 12 Jan 1992 08:34:23 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sun, 12 Jan 1992 08:28:41 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12015>; Sun, 12 Jan 1992 08:28:13 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <12015>; Sun, 12 Jan 1992 08:27:28 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA24280g; Sun, 12 Jan 92 08:23:59 PST
Received: by boston-harbor id AA05373g; Sun, 12 Jan 92 11:28:10 EST
X-NS-Transport-ID: 08002008D0FD0015C863
Message-ID: <9201121628.AA05373@boston-harbor>
Date:	Sun, 12 Jan 1992 08:28:10 -0800
From:	Judy Anderson <yduj@lucid.com>
To:	moo-cows.PARC@xerox.com
Subject: set_task_perms()


Currently, you get an error if you do set_task_persm() to a non-player
object.  I think that this is wrong, and it should be possible to set
perms to a non-player object.

It is relatively simple for a verb to be running with non-player perms
(simply by removing the player flag of someone who wrote a verb).  A
lot of core verbs start out with set_task_perms(caller_perms()).

This would also trivially solve the lambdamoo puppet problem, which
sets player to the puppet object (and since even core more verbs start
out with set_task_perms(player), this actually comes up in practice.
"Take" is the most common puppet lossage.  (Now, you can argue that
the way Gary_Severn (well, Dukas, actually) did puppets is wrong or
abuseful, but I think it was rather clever, and should work.)

Is there any reason that set_task_perms shouldn't work for any object,
valid or not?  I presume you can also have a verb running with
someone's recycled perms, although we didn't actually test this (it
being less destructive to set_player_flag on a test object than it is
to recycle that test object, and me having fear-of-large-numbers
leading to hating recycling...)

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu

From phyvs1.anu.edu.au!dxb105 Mon Jan 13 20:08:38 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28114>; Mon, 13 Jan 1992 20:08:35 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11752>; Mon, 13 Jan 1992 20:08:08 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11750>; Mon, 13 Jan 1992 20:05:00 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 13 Jan 1992 20:03:00 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11744>; Mon, 13 Jan 1992 20:02:24 PST
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <11744>; Mon, 13 Jan 1992 20:01:35 PST
Received: by phys.anu.edu.au (MX V2.3) id 29379; Tue, 14 Jan 1992 14:34:46 EST
X-NS-Transport-ID: 08002008D0FD0015D868
Message-ID: <00954A06.DD6794E0.29379@phys.anu.edu.au>
Date:	Tue, 14 Jan 1992 11:34:46 -0800
From:	David Bofinger <dxb105@phyvs1.anu.edu.au>
To:	MOO-Cows.PARC@xerox.com
cc:	dxb105@phyvs1.anu.edu.au
Subject: set_task_perms()

>Currently, you get an error if you do set_task_persm() to a non-player
>object.  I think that this is wrong, and it should be possible to set
>perms to a non-player object.

Well, if nobody else is going to reply I'll say I'm in favour. Presumably a
non-player object would usually have no special rights at all? (It wouldn't
have authority over it's owner, for example?) Could a normal programmer
set_task_perms() to one of eir own objects, thus disabling special powers?
(Perhaps that could be used as a method of allowing a player to disable one of
eir verbs, e.g. if it were written by someone else as part of a game.)

> (Now, you can argue that
>the way Gary_Severn (well, Dukas, actually) did puppets is wrong or
>abuseful, but I think it was rather clever, and should work.)

I don't know how else it could be done -- it would be much easier to argue I
should never have done it at all than that I did it the wrong way.

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
		MOO:	Ghost_Severn, Black_Nowhere, etc.
------------------------------------------------------------------------------

From morticia.cnns.unt.edu!cluther Tue Jan 14 10:19:34 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28130>; Tue, 14 Jan 1992 10:19:28 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11844>; Tue, 14 Jan 1992 10:18:56 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11811>; Tue, 14 Jan 1992 10:11:01 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 14 Jan 1992 10:09:04 -0800
Received: from morticia ([129.120.4.5]) by alpha.xerox.com with SMTP id <11831>; Tue, 14 Jan 1992 10:08:23 PST
Received: by morticia (4.1/1.36)
	id AA15759; Tue, 14 Jan 92 12:08:19 CST
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	cluther@morticia.cnns.unt.edu@morticia.cnns.unt.edu (Clay Luther)
					     ^-illegal special character in phrase
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD0015DE7E
Message-ID: <9201141808.AA15759@morticia>
Date:	Tue, 14 Jan 1992 10:08:18 -0800
From:	cluther@morticia.cnns.unt.edu
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: The Help System

Well, we are trying to decipher the mysteries of the help system on the GodNet,
and since their is no help on help, I thought I would ask here.

1)  How do you modify a help message in the help system (add, change, or
delete)?  Specifically, we would like to add a few new things and remove the 
LambdaMoo specific helps.

Hmmm...well, that's a mouthful I suppose.  Also, we fixed some database errors
in $time_utils if anyone is interested.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               GB-Free in '93.

From parc.xerox.com!pavel Tue Jan 14 12:06:59 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28142>; Tue, 14 Jan 1992 12:06:56 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11875>; Tue, 14 Jan 1992 12:06:12 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11895>; Tue, 14 Jan 1992 12:01:17 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 14 Jan 1992 11:56:56 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11856>; Tue, 14 Jan 1992 11:56:21 PST
Received: by lambda.parc.xerox.com id <58371>; Tue, 14 Jan 1992 11:56:11 -0800
X-NS-Transport-ID: 08002008D0FD0015E046
In-Reply-to: <9201141808.AA15759@morticia>
Message-ID: <92Jan14.115611pst.58371@lambda.parc.xerox.com>
Date:	Tue, 14 Jan 1992 11:56:01 -0800
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	moo-cows@parc.xerox.com
Subject: Re: The Help System

cluther@morticia.cnns.unt.edu writes:
> 1)  How do you modify a help message in the help system (add, change, or
> delete)?  Specifically, we would like to add a few new things and remove the 
> LambdaMoo specific helps.

Take a look at the description of $generic_help; it describes the protocol
pretty well.  If that doesn't cover it for you, let me know and I'll say more.

> Also, we fixed some database errors in $time_utils if anyone is interested.

I'm sure we'd like to see any bug fixes you've got.  Feel free to send them to
MOO-Cows if you can't send them to *Wizards on LambdaMOO.

	Pavel

From morticia.cnns.unt.edu!cluther Tue Jan 14 12:25:22 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28143>; Tue, 14 Jan 1992 12:25:19 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11882>; Tue, 14 Jan 1992 12:24:47 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11878>; Tue, 14 Jan 1992 12:21:47 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 14 Jan 1992 12:19:57 -0800
Received: from morticia ([129.120.4.5]) by alpha.xerox.com with SMTP id <11878>; Tue, 14 Jan 1992 12:19:28 PST
Received: by morticia (4.1/1.36)
	id AA16282; Tue, 14 Jan 92 14:19:26 CST
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	cluther@morticia.cnns.unt.edu@morticia.cnns.unt.edu (Clay Luther)
					     ^-illegal special character in phrase
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD0015E094
In-Reply-to: "<92Jan14.115611pst.58371@lambda.parc.xerox.com>; from \"Pavel Curtis\" at Jan 14, 92 11:56 am   "
Message-ID: <9201142019.AA16282@morticia>
Date:	Tue, 14 Jan 1992 12:19:25 -0800
From:	cluther@morticia.cnns.unt.edu
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: The Help System

Pavel Curtis (>) writes:
> 
> cluther@morticia.cnns.unt.edu writes:
> > 1)  How do you modify a help message in the help system (add, change, or
> > delete)?  Specifically, we would like to add a few new things and remove the 
> > LambdaMoo specific helps.
> 
> Take a look at the description of $generic_help; it describes the protocol
> pretty well.  If that doesn't cover it for you, let me know and I'll say more.

Unfortunately, $generic_help is not a defined property on #0.  But, you must
have meant $help....In any case, it looks reasonable.

> > Also, we fixed some database errors in $time_utils if anyone is interested.
> 
> I'm sure we'd like to see any bug fixes you've got.  Feel free to send them to
> MOO-Cows if you can't send them to *Wizards on LambdaMOO.

These were trivial.  Both $time_utils:day() and $time_utils:month() need to
have the time_utils container redefined to $time_utils (the code assumes
time_utils = #some_object_not_in_a_core_database).

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               GB-Free in '93.

From lucid.com!yduj Tue Jan 14 12:26:13 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28142>; Tue, 14 Jan 1992 12:26:05 -0800
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11881>; Tue, 14 Jan 1992 12:25:36 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA02108g; Tue, 14 Jan 92 12:22:00 PST
Received: by boston-harbor id AA12202g; Tue, 14 Jan 92 15:26:16 EST
Message-Id: <9201142026.AA12202@boston-harbor>
In-Reply-To: Pavel Curtis's message of Tue, 14 Jan 1992 11:56:01 PST <92Jan14.115611pst.58371@lambda.parc.xerox.com>
Date:	Tue, 14 Jan 1992 12:26:16 -0800
From:	Judy Anderson <yduj@lucid.com>
To:	pavel@parc.xerox.com
Cc:	moo-cows@parc.xerox.com
Subject: The Help System

Clay's core is older than $generic_help...

However the procedure for adding help entries is simple.  Simply add a
new property to $help with the name you'd like to have.  Help
properties in their simplest invocation are simply a list of strings.
Check $help.description for gory details.  (In general, looking at
various $ utilities will provide some documentation.)

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu

From lucid.com!yduj Tue Jan 14 13:04:08 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28142>; Tue, 14 Jan 1992 13:03:57 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11905>; Tue, 14 Jan 1992 13:03:06 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11838>; Tue, 14 Jan 1992 13:01:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 14 Jan 1992 13:00:02 -0800
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11900>; Tue, 14 Jan 1992 12:59:35 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA02265g; Tue, 14 Jan 92 12:56:03 PST
Received: by boston-harbor id AA12282g; Tue, 14 Jan 92 16:00:20 EST
X-NS-Transport-ID: 08002008D0FD0015E12F
In-Reply-to: "cluther@morticia.cnns.unt.edu's message of Tue, 14 Jan 1992 12:19:25 PST <9201142019.AA16282@morticia>"
Message-ID: <9201142100.AA12282@boston-harbor>
Date:	Tue, 14 Jan 1992 13:00:20 -0800
From:	Judy Anderson <yduj@lucid.com>
To:	moo-cows@parc.xerox.com
Subject: $time_utils

>These were trivial.  Both $time_utils:day() and $time_utils:month() need to
>have the time_utils container redefined to $time_utils (the code assumes
>time_utils = #some_object_not_in_a_core_database).

Fixed on LambdaMOO.  Actually, what I did was to remove the variable
entirely and make these references into "this".

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu


From maths.tcd.ie!chughes Wed Jan 15 18:22:31 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28219>; Wed, 15 Jan 1992 18:22:20 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11801>; Wed, 15 Jan 1992 18:22:01 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11772>; Wed, 15 Jan 1992 18:17:37 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 15 Jan 1992 18:16:03 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11772>; Wed, 15 Jan 1992 18:15:38 PST
Received: from salmon.maths.tcd.ie ([134.226.81.11]) by alpha.xerox.com with SMTP id <11763>; Wed, 15 Jan 1992 18:14:48 PST
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie  Via SMTP (FibreOptic)
          id aa24429; 16 Jan 92 2:14 GMT
X-NS-Transport-ID: 08002008D0FD0015F3D9
Message-ID: <9201160214.aa24429@salmon.maths.tcd.ie>
Date:	Wed, 15 Jan 1992 18:14:42 -0800
From:	Conrad Hughes <chughes@maths.tcd.ie>
To:	moo-cows.PARC@xerox.com
Subject: Perms on initialize


I'm not sure if this has been discussed before, but why are the
perms with which child:initialize() is called those of the
caller of parent:create()?  It seems a bit strange when I call
create(obj,own) that the permissions with which child:initialize
is called are mine, rather than those either of own or of
obj.owner (own seems more logical).  The reason I ask is that I
would like to be able to move create into the database so that
most verbs call $creation_utils:create(obj,own) rather than
create(obj,own) - under these circumstances I can mess with
creation without the risk of the caller causing me to call a
nasty initialize verb with wizard permissions.

Conrad

From parc.xerox.com!pavel Thu Jan 16 15:47:42 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28257>; Thu, 16 Jan 1992 15:47:40 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11628>; Thu, 16 Jan 1992 15:47:17 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11659>; Thu, 16 Jan 1992 15:44:17 PST
Received: by lambda.parc.xerox.com id <58371>; Thu, 16 Jan 1992 15:42:21 -0800
X-NS-Transport-ID: 08002008D0FD00160193
In-Reply-to: <9201160214.aa24429@salmon.maths.tcd.ie>
Message-ID: <92Jan16.154221pst.58371@lambda.parc.xerox.com>
Date:	Thu, 16 Jan 1992 15:42:19 -0800
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Re: Perms on initialize

Conrad Hughes writes:

> I'm not sure if this has been discussed before, but why are the perms with
> which child:initialize() is called those of the caller of parent:create()?

In all cases where a built-in function calls back into MOO code, the called MOO
verb appears to have been invoked by the verb that called the built-in
function.

> It seems a bit strange when I call create(obj,own) that the permissions with
> which child:initialize is called are mine, rather than those either of own or
> of obj.owner (own seems more logical).  The reason I ask is that I would like
> to be able to move create into the database so that most verbs call
> $creation_utils:create(obj,own) rather than create(obj,own) - under these
> circumstances I can mess with creation without the risk of the caller causing
> me to call a nasty initialize verb with wizard permissions.

I don't understand your concern.  The :initialize verb is still going to run
using the permissions of its authors, so why do you care that the calling verb
has wizard permissions?

	Pavel/Haakon

From att1.mankato.msus.edu!nop Thu Jan 23 16:58:11 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28423>; Thu, 23 Jan 1992 16:58:08 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12204>; Thu, 23 Jan 1992 16:50:36 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12097>; Thu, 23 Jan 1992 16:33:49 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 23 Jan 1992 16:30:51 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12112>; Thu, 23 Jan 1992 16:29:31 PST
Received: from att1.Mankato.MSUS.EDU ([134.29.1.7]) by alpha.xerox.com with SMTP id <12088>; Thu, 23 Jan 1992 16:28:25 PST
Received:  by att1.Mankato.MSUS.EDU (5.59/25-eef)
	id AA29686; Thu, 23 Jan 92 18:24:41 CST
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	Jay A.Carlson <nop@att1.Mankato.MSUS.EDU>
		^    ^-illegal period in phrase
		 \-phrases containing '.' must be quoted
X-NS-Transport-ID: 08002008D0FD0016575D
Message-ID: <9201240024.AA29686@att1.Mankato.MSUS.EDU>
Date:	Thu, 23 Jan 1992 16:24:41 -0800
From:	nop@att1.mankato.msus.edu
To:	moo-cows.PARC@xerox.com
Subject: Half-baked data type ideas


JoeFeedback and I are toying with a Minimal.db.  As well as coming up
with a weird restructuring of :tell/:announce, we started thinking
about names for utility objects.  We came to the conclusion that
instead of having $string_utils and $list_utils, we should just have
$string and $list, and in fact, have $integer and $error and $object
as well.  These would inherit from $type, which would define protocol
for operations like :to_string() and :from_string() and like that.

$type would mostly be an abstract superclass; we talked about making
$type effectively call `self subClassResponsibility' for most of its
methods.

We also considered $alist, a descendent of $list, as a place to put all
those nifty assoc-related verbs.

Since Haakon assured me that it was OK to air half-baked ideas on
MOO-Cows, here's one:

Hack the server to allow verb calls on non-objects.  Instead of
`1234:to_string()' causing a type error, it would route the call to
`$integer:to_string()'.  Either 1234 would be added to the
:to_string() argument lists, or `this' would be set to 1234.  Similar
redirection would be done for the other data types, except for
objects, obviously.

Unfortunately, this doesn't provide any nice way to provide for
user-defined data subtypes.  All instances of the MOO data structure
type, the list, would have the same method suite.  $alist's would have
the same methods as $list's.  So here's half-baked idea number two:

Associate a `class' attribute with certain lists.  Make the class
accessible through a few new primitives.  Lists would otherwise appear
exactly the same, except when verbs are called on them.

Alternative idea:  Treat lists of the form {E_TYPE, #class,
internaldata, internaldata, ...} differently in the verb dispatcher.
Refer all calls to #class.  This has the disadvantage of disallowing
implicit list operations on lists that start with E_TYPE (let me know
if you've ever seen one :-) but would still allow explicit
`$list:foo({E_TYPE, ...})' data typing calls.

Lemme know what you think.  If you have any ideas for cores built from
Minimal.db, tell me or JoeFeedback.

       ---Jonny

  // Jay Carlson
\X/  nop@att1.mankato.msus.edu

To subscribe to the MC68HC11 list, email to mc68hc11-request@elden.cse.nau.edu.

From parc.xerox.com!masinter Thu Jan 23 19:10:38 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28426>; Thu, 23 Jan 1992 19:10:28 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12196>; Thu, 23 Jan 1992 18:59:54 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12081>; Thu, 23 Jan 1992 18:55:01 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 23 Jan 1992 18:52:21 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12309>; Thu, 23 Jan 1992 18:48:52 PST
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <12308>; Thu, 23 Jan 1992 18:46:58 PST
Received: by poplar.parc.xerox.com id <99277>; Thu, 23 Jan 1992 18:46:44 -0800
Fake-Sender: masinter@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00165902
In-Reply-to: "nop@att1.mankato.msus.edu's message of Thu, 23 Jan 1992 18:34:57 -0800 <92Jan23.183511pst.99277@poplar.parc.xerox.com>"
Message-ID: <92Jan23.184644pst.99277@poplar.parc.xerox.com>
Date:	Thu, 23 Jan 1992 18:46:32 -0800
From:	Larry Masinter <masinter@parc.xerox.com>
To:	nop@att1.mankato.msus.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: Half-baked data type ideas

It is a mistake to think of $alist as a kind of a $list. Lisp systems
that tried to do this failed, since they aren't proper subtypes, it is
reasonable to construct something "as a list" and then treat it "as an
alist", and deciding whether any arbitrary list structure could be
treated "as an alist" isn't easy. There's a limit to what you can
expect from a type hierarchy; you wouldn't expect to have $prime or
$even, even though there are sets of primes and evens as subsets of
$integer.

It is OK to disallow user-defined data subtypes of built-in types. It
makes no sense to define subtypes of $integer, since it isn't an
extensible type. I would suggest instead that you make a type called
$number, and make $integer inherit from $number. Users can define
other kinds of $numbers, too. Things that really made sense for
moo-numbers only would go to $integer, while other methods would just
go on $number. 

Alternatively, you might just define $string and $integer to be
abstract, and $moo_string and $moo_number to be the classes that are
called.

MOO already has a nice class system, and most of the generality you
need can be done without hacking up another one with special lists
that start with special codes. 





From morticia.cnns.unt.edu!cluther Fri Jan 24 14:13:53 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28474>; Fri, 24 Jan 1992 14:13:47 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11782>; Fri, 24 Jan 1992 14:13:02 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11711>; Fri, 24 Jan 1992 14:09:03 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 24 Jan 1992 14:06:26 -0800
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11559>; Fri, 24 Jan 1992 14:06:05 PST
Received: by morticia.cnns.unt.edu id AA11665
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Fri, 24 Jan 1992 16:06:01 -0600
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD0016651C
Message-ID: <199201242206.AA11665@morticia.cnns.unt.edu>
Date:	Fri, 24 Jan 1992 14:06:00 -0800
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Suggested method for creating a string in the server

I am adding some functions to the moo server and one of the functions needs
a buffer string to work on.  The exact nature of the call is

foo(anon *p; char *c; char *buf);

Foo works on data from p and c, storing to buf.  The string at buf will
finally be returned to the server.  The problem, of course, is guessing how
big a buf one needs in the first place.

Currently, I am working with this algorithm:

buf = (char *)malloc(some_big_size);
foo(p,c,buf);
r.v.str = strdup(buf);
free(buf);


If there is a better, more Pavelish way, please let me know.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               GB-Free in '93.

From parc.xerox.com!pavel Fri Jan 24 16:49:59 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28482>; Fri, 24 Jan 1992 16:49:51 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11811>; Fri, 24 Jan 1992 16:49:19 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11806>; Fri, 24 Jan 1992 16:45:44 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 24 Jan 1992 16:42:19 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11800>; Fri, 24 Jan 1992 16:41:53 PST
Received: by lambda.parc.xerox.com id <58371>; Fri, 24 Jan 1992 16:41:44 -0800
X-NS-Transport-ID: 08002008D0FD001667D6
In-Reply-to: <199201242206.AA11665@morticia.cnns.unt.edu>
Message-ID: <92Jan24.164144pst.58371@lambda.parc.xerox.com>
Date:	Fri, 24 Jan 1992 16:41:34 -0800
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	cluther@morticia.cnns.unt.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: Suggested method for creating a string in the server

Clay Luther writes:
> I am adding some functions to the moo server and one of the functions needs a
> buffer string to work on...  The problem, of course, is guessing how big a
> buf one needs in the first place.

The right way to do this is to use the functions declared in streams.h:

	extern Stream  *new_stream(int size);
	extern void	stream_add_char(Stream *, char);
	extern void	stream_add_string(Stream *, const char *);
	extern void	stream_printf(Stream *, const char *, ...);
	extern void	free_stream(Stream *);
	extern char    *stream_contents(Stream *);
	extern char    *reset_stream(Stream *);
	extern int	stream_length(Stream *);

Use new_stream() to get a stream to write on; the argument is a guess at how
many characters you'll write, but it doesn't matter if you're wrong.  Then use
stream_add_char(), stream_add_string(), and stream_printf() to add stuff onto
the end of the stream.  (Note: stream_printf() can only handle %s and %d, not
all of printf.)  At any time, you can use stream_length() to see how many
characters you've got in there so far and stream_contents() to get your hands
on the underlying string itself, null-terminated and all.  reset_stream() both
returns the underlying null-terminated string and changes the state of the
stream to say that it's empty again; this is useful for when you want to reuse
the stream for some other purpose, avoiding the cost of freeing this stream and
making a new one.  Finally, when you're done with the stream, use free_stream()
to get rid of it cleanly.

Note that you should finish using the string returned by stream_contents() and
reset_stream() before calling any of stream_add_char(), stream_add_string(),
stream_printf(), or free_stream() on the corresponding stream; using strdup()
on it is a common way of obeying this rule.

	Pavel

From silver.cs.umanitoba.ca!charlto Mon Feb  3 14:21:00 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28107>; Mon, 3 Feb 1992 14:20:50 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11656>; Mon, 3 Feb 1992 14:19:55 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11634>; Mon, 3 Feb 1992 14:12:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 3 Feb 1992 14:08:12 -0800
Received: from ccu.UManitoba.CA ([130.179.16.8]) by alpha.xerox.com with SMTP id <11669>; Mon, 3 Feb 1992 14:06:02 PST
Received: from silver.cs.UManitoba.CA by ccu.UManitoba.CA
	(4.1/25-eef) id AA27572; Mon, 3 Feb 92 16:06:04 CST
Received:  by silver.cs.UManitoba.CA
	(4.1/25-eef) id AA09389; Mon, 3 Feb 92 16:08:01 CST
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	Michael K.Charlton <charlto@silver.cs.UManitoba.CA>
		^	 ^-illegal period in phrase
		 \-phrases containing '.' must be quoted
X-NS-Transport-ID: 08002008D0FD0016DD4B
Message-ID: <9202032208.AA09389@silver.cs.UManitoba.CA>
Date:	Mon, 3 Feb 1992 14:08:01 -0800
From:	charlto@silver.cs.umanitoba.ca
To:	moo-cows@parc.xerox.com
Subject: Ambiguity of Objects

Hello.  My brother and I are running into some problems with putting
verbs on objects when there is an ambiguity problem with the object.
For instance we are trying to make a pub where you can buy beer.  The
verb "drink" is on the beer object.  The problem comes when you have 2
beers in your posession and try to drink one.  Basically, because the
object "beer" is ambiguous, the parser won't recognize the "drink"
verb.  Is there any way around this?  The only thing we can think of
is to give each beer a unique name (which is ludicrous) or put a front
end command on the player for every verb s/he might use on an object
(this is only slightly less ludicrous).  Any ideas?  For this
particular problem, I suppose we COULD put "drink" on the player, but
this is going to happen quite frequently with other objects and verbs.
We would rather be able to put the verbs on the objects than have a
zillion nearly useless verbs on the players and rooms.
     Thanks for the help,
             Mike
P.S.  We don't want to change the parser.  We would like our code to
work on a generic MOO.

From xerox.com!parc.xerox.com.PARC Mon Feb  3 14:37:14 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28107>; Mon, 3 Feb 1992 14:37:09 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11642>; Mon, 3 Feb 1992 14:36:46 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11656>; Mon, 3 Feb 1992 14:33:08 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 3 Feb 1992 14:29:22 -0800
Received: from po2.andrew.cmu.edu ([128.2.249.105]) by alpha.xerox.com with SMTP id <11659>; Mon, 3 Feb 1992 14:28:57 PST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA07461> for moo-cows@parc.xerox.com; Mon, 3 Feb 92 17:28:47 EST
Received: via switchmail; Mon,  3 Feb 1992 17:28:44 -0500 (EST)
Received: from pcs3.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.wdXQ6bq00Uh7E0c7gG>;
          Mon,  3 Feb 1992 17:26:49 -0500 (EST)
Received: from pcs3.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr17/ss72/.Outgoing/QF.UdXQ6Xi00Uh787SX4Q>;
          Mon,  3 Feb 1992 17:26:44 -0500 (EST)
Received: from mms.0.1.873.MacMail.0.9.CUILIB.3.45.SNAP.NOT.LINKED.pcs3.andrew.cmu.edu.pmax.ul4
          via MS.5.6.pcs3.andrew.cmu.edu.pmax_ul4;
          Mon,  3 Feb 1992 17:26:43 -0500 (EST)
X-NS-Transport-ID: 08002008D0FD0016DD9C
In-Reply-to: <9202032208.AA09389@silver.cs.UManitoba.CA>
Message-ID: <0dXQ6Xe00Uh7A7SWxQ@andrew.cmu.edu>
References: <9202032208.AA09389@silver.cs.UManitoba.CA>
Date:	Mon, 3 Feb 1992 14:26:43 -0800
From:	Sean Christopher Simmons <ss72+@andrew.cmu.edu>
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: Re: Ambiguity of Objects

This is a problem with the parser.  I have been looking into this
problem for a project of my own, and although I have not had time to
check it out, I've been told that you can solve the problem by changing
the definition of match_object.  I'm a little skeptical, as I thought
that would only fix matching for dobj and iobj at best, but you might
look at that.


===============================================================================
|     "jaa, na"                                                         
     | 
| Shin -- ss72@andrew.cmu.edu			Junior Undergrad CS           |
|      (Sean Simmons)                           Carnegie-Mellon University    |
===============================================================================

From lucid.com!yduj Mon Feb  3 15:13:03 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28111>; Mon, 3 Feb 1992 15:12:54 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11700>; Mon, 3 Feb 1992 15:12:29 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11717>; Mon, 3 Feb 1992 15:10:04 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 3 Feb 1992 15:05:00 -0800
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11688>; Mon, 3 Feb 1992 15:04:17 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA02625g; Mon, 3 Feb 92 14:59:59 PST
Received: by boston-harbor id AA06034g; Mon, 3 Feb 92 18:05:14 EST
X-NS-Transport-ID: 08002008D0FD0016DE26
In-Reply-to: "charlto@silver.cs.umanitoba.ca's message of Mon, 3 Feb 1992 14:08:01 PST <9202032208.AA09389@silver.cs.UManitoba.CA>"
Message-ID: <9202032305.AA06034@boston-harbor>
Date:	Mon, 3 Feb 1992 15:05:14 -0800
From:	Judy Anderson <yduj@lucid.com>
To:	charlto@silver.cs.umanitoba.ca
cc:	moo-cows@parc.xerox.com
Subject: Ambiguity of Objects

This problem has been addressed a little bit on LambdaMOO, with the
Matching Room, #3879, which defines a :huh2 verb (which gets called by
$room:huh).  The way it works is you say things like "drink my beer"
to disambiguate the beer in your inventory from the beer on the table,
and "get first beer" to pick up a beer (the first one in the room's
contents list in this case).  I don't think the Matching Room has been
included in the LambdaCore distribution.

yduJ on LambdaMOO        yduJ@lucid.com      'yduJ' rhymes with 'fudge'
    [ LambdaMOO is lambda.parc.xerox.com 8888 / 13.2.116.36 8888 ]
   Join the League for Programming Freedom, league@prep.ai.mit.edu


From cc.ysu.edu!doug Mon Feb  3 16:22:59 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28117>; Mon, 3 Feb 1992 16:22:57 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11699>; Mon, 3 Feb 1992 16:20:33 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11679>; Mon, 3 Feb 1992 16:18:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Mon, 3 Feb 1992 16:14:45 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11672>; Mon, 3 Feb 1992 16:11:07 PST
Received: from cc.ysu.edu ([192.55.234.50]) by alpha.xerox.com with SMTP id <11701>; Mon, 3 Feb 1992 14:54:55 PST
Received: by cc.ysu.edu id AA14526
  (5.65c/IDA-1.4.4 for moo-cows@xerox.com); Mon, 3 Feb 1992 17:52:49 -0500
Organization: Youngstown State University
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0016DE09
Message-ID: <199202032252.AA14526@cc.ysu.edu>
Date:	Mon, 3 Feb 1992 14:52:48 -0800
From:	Doug Sewell <doug@cc.ysu.edu>
To:	moo-cows.PARC@xerox.com
Subject: Anyone done a port to SVR3 ?

Has anyone ported (successfully or not) moo to SVR3 ?

We have an old NCR Tower that will soon be decommissioned.  This box
is SVR3, with WIN/TCP and a K&R-ish compiler.  The WIN code is BSD4-ish
TCP.

I managed to deal with the 14-character filenames and updating a few
includes to pull in required/moved files, based on -DNCR, and added
-I/usr/netinclude in the CFLAGS.

I tried to build it and the compiler disliked the prototypes.  While
I can go track down ansi2kr or another prototype-fixer, it it worth
the trouble ?  If nothing else, I'll always be a step or two (at least)
behind the current server release.

Any comments ?
-- 
Doug Sewell, Tech Support, Computer Center, Youngstown State University
doug@cc.ysu.edu doug@ysub.bitnet uunet!cc.ysu.edu!doug
cat core | uuencode bunny.dropping | mail jp@tygra.michigan.com

From cc.ysu.edu!doug Tue Feb  4 15:12:46 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28191>; Tue, 4 Feb 1992 15:12:33 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11834>; Tue, 4 Feb 1992 15:11:28 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11813>; Tue, 4 Feb 1992 15:07:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 4 Feb 1992 14:57:00 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11812>; Tue, 4 Feb 1992 14:53:54 PST
Received: from cc.ysu.edu ([192.55.234.50]) by alpha.xerox.com with SMTP id <11602>; Tue, 4 Feb 1992 14:52:34 PST
Received: by cc.ysu.edu id AA06048
  (5.65c/IDA-1.4.4 for moo-cows@xerox.com); Tue, 4 Feb 1992 17:50:20 -0500
Organization: Youngstown State University
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0016EE96
Message-ID: <199202042250.AA06048@cc.ysu.edu>
Date:	Tue, 4 Feb 1992 14:50:20 -0800
From:	Doug Sewell <doug@cc.ysu.edu>
To:	moo-cows.PARC@xerox.com
Subject: Porting moo to SVR3 - results

In short, no go.

I covered the filename-length restriction, special includes for WIN/TCP,
variations on include names from BSD to SysV.

I built "unproto" to strip the prototypes out on-the-fly.  Worked well,
but I had to redefine const to null.   

Then I got to the "wait3" call.  No dice, doesn't appear to be any
easy way to do it based on my experience either.

Oh well... it was an interesting learning experience.
--
-- 
Doug Sewell, Tech Support, Computer Center, Youngstown State University
doug@cc.ysu.edu doug@ysub.bitnet uunet!cc.ysu.edu!doug
cat core | uuencode bunny.dropping | mail jp@tygra.michigan.com

From pavel Tue Feb  4 17:38:44 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from lambda.parc.xerox.com ([13.2.116.36]) by palain.parc.xerox.com with SMTP id <28194>; Tue, 4 Feb 1992 17:38:37 -0800
Received: by lambda.parc.xerox.com id <58372>; Tue, 4 Feb 1992 17:38:20 -0800
In-reply-to: <199202042250.AA06048@cc.ysu.edu>
Message-Id: <92Feb4.173820pst.58372@lambda.parc.xerox.com>
Date:	Tue, 4 Feb 1992 17:38:16 -0800
From:	Pavel Curtis <pavel>
To:	doug@cc.ysu.edu
CC:	Pavel
Subject: Re: Porting moo to SVR3 - results

> In short, no go.

Don't give up yet!

> Then I got to the "wait3" call.  No dice, doesn't appear to be any
> easy way to do it based on my experience either.

I think there's a way.  I just spent some time tracking down some SVR3
documentation and found the following loophole, but I'm not able to test it,
since I don't have access to any SVR3 machines.

In SVR3, there is a signal named SIGCLD (or, maybe, the same as in BSD:
SIGCHLD; my sources were inconsistent).  It is raised in a parent process
whenever a child process terminates.  The default behavior is that it is
ignored by the parent process and the child process becomes a `zombie' process,
which must be wait()ed for in order to get cleared from the process table.

If you do signal(SIGCLD, SIG_IGN), this is *different* than the default.  As
before, the signal is ignored by the parent, but in this case the child *does
not* become a zombie; it just goes away.

Right now, I catch SIGCHLD with child_completed_signal(), which does the wait()
call.  The problem with using this strategy in SVR3 is that it's possible to
have more than one child terminate sufficiently simultaneously that the parent
sees only *one* signal.  On BSD or POSIX, I can simply use the NOHANG option to
wait3() or waitpid() to loop doing waits until there're no more children.

On SVR3, you could signal(SIGCLD, SIG_IGN) instead, and simply excise the
function child_completed_signal() completely, solving your problem.

	Pavel

From morticia.cnns.unt.edu!cluther Thu Feb  6 15:03:00 1992
X-VM-v5-Data: ([nil nil nil t nil nil nil nil nil]
	[nil "Thu" "6" "February" "1992" "14:45:28" "-0800" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "3844" "Regexp, List Utils patch to the Moo Server" "^Date:" nil nil "2"])
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28385>; Thu, 6 Feb 1992 15:02:53 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11730>; Thu, 6 Feb 1992 15:01:32 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11682>; Thu, 6 Feb 1992 14:57:41 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 6 Feb 1992 14:47:03 -0800
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11701>; Thu, 6 Feb 1992 14:46:10 PST
Received: by morticia.cnns.unt.edu id AA11913
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Thu, 6 Feb 1992 16:45:30 -0600
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001710E8
Message-ID: <199202062245.AA11913@morticia.cnns.unt.edu>
Date:	Thu, 6 Feb 1992 14:45:28 -0800
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Regexp, List Utils patch to the Moo Server

What follows is a shar file of the regular expression and list utils
additions we have made to the GodNet moo server.

The list utils additions are minor server optimizations.  However, the
regular expression primitives are important and valuable additions to the
moo server (imho ;)).

The regular expression primitives are based on Henry Spencer's regexp
library.

The GodNet moo server, gnoo, is also available via anonymous ftp from
morticia.cnns.unt.edu, /pub/mud.

----------- cut here
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  README.gnoo REGEXP moo.patch regerror.c regexp.3 regexp.c
#   regexp.c.orig regexp.h regmagic.h regsub.c
# Wrapped by cluther@morticia on Thu Feb  6 16:40:55 1992
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'README.gnoo' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'README.gnoo'\"
else
echo shar: Extracting \"'README.gnoo'\" \(1057 characters\)
sed "s/^X//" >'README.gnoo' <<'END_OF_FILE'
XThese are the current GodNet patches to the Moo server.  They include the 
Xaddition of the regular expression parser and substitution mechanism and a
Xthe addition of listassoc() and listiassoc() primitives.
X
XFor more information on the regular expression primitives, see the file
XREGEXP.
X
XListassoc() and listiassoc() implement the LambdaCore $list_utils verbs
Xassoc() and iassoc() in the server.  This was done since, in the GodNet at 
Xleast, we found that the $list_utils was a bottleneck.  Since assoc() and
Xiassoc() were used in over 130 verb calls, worked only an primitive datatypes,
Xand were demonstrably slow, we moved these functions to the server.  As a 
Xresult, we have seen a marked increase in many verbs, from the @mail suite to
Xthe player database. [We changed $list_utils:assoc() and :iassoc() to call the
Xprimitives for backward compatibility]
X
XIf you have any questions or suggestions, or if you find a bug, PLEASE send
Xemail to me.
X
XThanks.  And enjoy.
X
XClay Luther
Xcluther@morticia.cnns.unt.edu
XMalraux@GodNet morticia.cnns.unt.edu 7777
END_OF_FILE
if test 1057 -ne `wc -c <'README.gnoo'`; then
    echo shar: \"'README.gnoo'\" unpacked with wrong size!
fi
# end of 'README.gnoo'
fi
if test -f 'REGEXP' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'REGEXP'\"
else
echo shar: Extracting \"'REGEXP'\" \(3428 characters\)
sed "s/^X//" >'REGEXP' <<'END_OF_FILE'
XREGEXP in MOO
X=============
X
XInstalled by Clay Luther
XFrom the regexp library written by Henry Spencer.
X
XVersion 1.5.9r of the server contains two additional functions, regexp() and
Xregsub().  This functions implement the Unix regular expression parser for Moo
Xprogrammers.  The full-range of regular expression parsing is brought to the 
XMoo programmer as a result.
X
X
X
XSYNTAX:
X
X  NUM regexp(STR regexpstr, STR string, [NUM case_matters])
X
X  regexp applies the regular expression found in regexpstr to string.  If a 
X  match is found, TRUE (1) is return, otherwise FALSE (0) is returned. (See 
X  the discussion of regular expressions that follows).
X
X  For example,
X
X  regexp(".* feels .*", "Malraux feels bad.") --> TRUE
X  regexp(".* feels .*", "Malraux eats bad carrots.") --> FALSE
X
X  The optional case_matters parameter is used to change the default behavior 
X  of the regular expression parser.  Normally, regexp() is case-insensitive.
X  If case_matters is non-zero (true), then regexp() performs a case-sensitive
X  parse.
X
X  STR regsub(STR regexp, STR string, STR pattern, [NUM case_matters])
X
X  regsub applies the regular expression found in regexpstr to string.  If a 
X  match is found, then a new string is created, using the substitution pattern
X  found in pattern.
X
X  The regexpstr must follow Unix regular expression rules for selecting 
X  pattern spaces.  That is, the pattern spaces you want to reference in the
X  pattern string must be surround by %( and %).  The pattern string deviates
X  slightly from standard Unix pattern space identification.  To identify a 
X  pattern space, you use % followed by a number, 1 to 9.  %0 returns the 
X  pattern space representing all matched strings.  (Normal Unix regexp 
X  requires a \ followed by a number to identify a pattern space.  Because the
X  Moo parser intercepts \, this would force the programmer to identify spaces
X  via \\n, which seemed unwieldy.)
X
X  If regsub() fails to match the regexpstr to string, a null string "" is 
X  returned.
X
X  For example,
X
X  regsub("(.*) feels (.*)%.", "Malraux feels bad.","Why do you feel %2, %1?")
X    --> "Why do you feel bad, Malraux?"
X
X  regsub("(.*) feels (.*)%.", "Malraux eats bad.","Why do you feel %2, %1?")
X    --> ""
X
X  NOTE:  In both cases, the ending punctuation period was "escaped" with %.
X
X
XREGULAR EXPRESSIONS and PATTERN MATCHING
X
XUnix has a rich and complicated definition of regular expressions.  
X
XPatterns may contain special characters:
X
X. == matches any single character.
X* == matches any number, including 0, of the single character, including .,
X     proceeding the *
X+ == matches *at least one* of the single character, include ., proceeding the
X     +
X[...] == matches any one character enclosed between [ and ]
X^ == requires the character to be at the beginning of the string
X$ == requires the proceeding character to be at the end of the string
X% == treat the next character as an ordinary character. (\\ in Moo)
X() == save the pattern enclosed between \( and \)
X%n == matches the nth pattern space
X& == prints the entire search pattern when used in replacement string.
X
XNOTE: Normal Unix regexp uses the \ character to escape regexp parsing.  Moo
X      regexp uses the % character instead.
X
X******************************************************************************
XMore information about regular expression pattern matching can be found in any
XUnix manual, or the BSD Unix in a Nutshell book.
END_OF_FILE
if test 3428 -ne `wc -c <'REGEXP'`; then
    echo shar: \"'REGEXP'\" unpacked with wrong size!
fi
# end of 'REGEXP'
fi
if test -f 'moo.patch' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'moo.patch'\"
else
echo shar: Extracting \"'moo.patch'\" \(15669 characters\)
sed "s/^X//" >'moo.patch' <<'END_OF_FILE'
Xdiff -c moo/ChangeLog.txt gnoo/ChangeLog.txt
X*** moo/ChangeLog.txt	Fri Dec  6 10:31:18 1991
X--- gnoo/ChangeLog.txt	Thu Feb  6 15:39:44 1992
X***************
X*** 377,379 ****
X--- 377,390 ----
X     either the movee or the destination.
X  -- Fixed several bugs in recycle() that could (and did!) corrupt the contents
X     hierarchy in the database.  The implementation is now much simpler, too!
X+ 
X+ Version 1.5.9r February 6th, 1992,
X+ by Clay Luther (cluther@morticia.cnns.unt.edu)
X+ 
X+ Completed the addition of the following primitives:
X+ 
X+   regexp()
X+   regsub()
X+   listassoc()
X+   listiassoc()
X+ 
Xdiff -c moo/Makefile gnoo/Makefile
X*** moo/Makefile	Fri Dec  6 10:30:40 1991
X--- gnoo/Makefile	Fri Jan 24 15:20:34 1992
X***************
X*** 89,101 ****
X  	chparent.c code_elt.c exceptions.c execute.c functions.c list.c log.c \
X  	malloc.c match.c parse_command.c program.c property.c quota.c \
X  	server.c storage.c streams.c tasks.c timers.c unparse.c utils.c \
X! 	vector.c version.c
X  
X  HDRS = bf_register.h bytecodes.h chparent.h code_elt.h config.h exceptions.h \
X  	execute.h functions.h getpagesize.h list.h log.h match.h network.h \
X  	opcode.h parse_command.h parser.h program.h property.h quota.h \
X  	random.h server.h streams.h structures.h tasks.h timers.h unparse.h \
X! 	utils.h vector.h version.h
X  
X  SYSHDRS = my-in.h my-ioctl.h my-signal.h my-socket.h my-stdarg.h my-stdio.h \
X  	my-stdlib.h my-string.h my-sys-time.h my-time.h my-types.h my-unistd.h
X--- 89,101 ----
X  	chparent.c code_elt.c exceptions.c execute.c functions.c list.c log.c \
X  	malloc.c match.c parse_command.c program.c property.c quota.c \
X  	server.c storage.c streams.c tasks.c timers.c unparse.c utils.c \
X! 	vector.c version.c regerror.c regexp.c regsub.c
X  
X  HDRS = bf_register.h bytecodes.h chparent.h code_elt.h config.h exceptions.h \
X  	execute.h functions.h getpagesize.h list.h log.h match.h network.h \
X  	opcode.h parse_command.h parser.h program.h property.h quota.h \
X  	random.h server.h streams.h structures.h tasks.h timers.h unparse.h \
X! 	utils.h vector.h version.h regmagic.h regexp.h
X  
X  SYSHDRS = my-in.h my-ioctl.h my-signal.h my-socket.h my-stdarg.h my-stdio.h \
X  	my-stdlib.h my-string.h my-sys-time.h my-time.h my-types.h my-unistd.h
X***************
X*** 176,184 ****
X    parse_command.h server.h network.h 
X  bf_num.o : bf_num.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h my-time.h random.h 
X! bf_obj.o : bf_obj.c functions.h structures.h my-stdio.h my-stdarg.h \
X!   bytecodes.h bf_register.h execute.h config.h opcode.h program.h list.h \
X!   utils.h chparent.h quota.h property.h server.h network.h 
X  bf_player.o : bf_player.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h execute.h config.h opcode.h program.h \
X    server.h network.h 
X--- 176,184 ----
X    parse_command.h server.h network.h 
X  bf_num.o : bf_num.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h my-time.h random.h 
X! bf_obj.o : bf_obj.c chparent.h structures.h my-stdio.h my-stdarg.h \
X!   bytecodes.h execute.h config.h opcode.h program.h functions.h bf_register.h \
X!   list.h property.h quota.h server.h network.h utils.h 
X  bf_player.o : bf_player.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h execute.h config.h opcode.h program.h \
X    server.h network.h 
X***************
X*** 187,193 ****
X  bf_server.o : bf_server.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h server.h network.h version.h 
X  bf_str_list.o : bf_str_list.c functions.h structures.h my-stdio.h \
X!   my-stdarg.h bytecodes.h bf_register.h list.h utils.h random.h my-string.h 
X  bf_task.o : bf_task.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h tasks.h execute.h config.h opcode.h \
X    program.h 
X--- 187,194 ----
X  bf_server.o : bf_server.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h server.h network.h version.h 
X  bf_str_list.o : bf_str_list.c functions.h structures.h my-stdio.h \
X!   my-stdarg.h bytecodes.h bf_register.h list.h utils.h random.h my-string.h \
X!   regexp.h 
X  bf_task.o : bf_task.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h tasks.h execute.h config.h opcode.h \
X    program.h 
X***************
X*** 257,262 ****
X--- 258,266 ----
X  vector.o : vector.c vector.h opcode.h code_elt.h my-stdarg.h my-string.h \
X    structures.h my-stdio.h bytecodes.h 
X  version.o : version.c version.h 
X+ regerror.o : regerror.c 
X+ regexp.o : regexp.c regexp.h regmagic.h 
X+ regsub.o : regsub.c regexp.h regmagic.h 
X  bi_create.po : bi_create.c match.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h property.h quota.h utils.h 
X  bf_move.po : bf_move.c my-stdio.h my-stdarg.h execute.h bytecodes.h config.h \
X***************
X*** 264,272 ****
X    parse_command.h server.h network.h 
X  bf_num.po : bf_num.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h my-time.h random.h 
X! bf_obj.po : bf_obj.c functions.h structures.h my-stdio.h my-stdarg.h \
X!   bytecodes.h bf_register.h execute.h config.h opcode.h program.h list.h \
X!   utils.h chparent.h quota.h property.h server.h network.h 
X  bf_player.po : bf_player.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h execute.h config.h opcode.h program.h \
X    server.h network.h 
X--- 268,276 ----
X    parse_command.h server.h network.h 
X  bf_num.po : bf_num.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h my-time.h random.h 
X! bf_obj.po : bf_obj.c chparent.h structures.h my-stdio.h my-stdarg.h \
X!   bytecodes.h execute.h config.h opcode.h program.h functions.h bf_register.h \
X!   list.h property.h quota.h server.h network.h utils.h 
X  bf_player.po : bf_player.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h execute.h config.h opcode.h program.h \
X    server.h network.h 
X***************
X*** 275,281 ****
X  bf_server.po : bf_server.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h server.h network.h version.h 
X  bf_str_list.po : bf_str_list.c functions.h structures.h my-stdio.h \
X!   my-stdarg.h bytecodes.h bf_register.h list.h utils.h random.h my-string.h 
X  bf_task.po : bf_task.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h tasks.h execute.h config.h opcode.h \
X    program.h 
X--- 279,286 ----
X  bf_server.po : bf_server.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h server.h network.h version.h 
X  bf_str_list.po : bf_str_list.c functions.h structures.h my-stdio.h \
X!   my-stdarg.h bytecodes.h bf_register.h list.h utils.h random.h my-string.h \
X!   regexp.h 
X  bf_task.po : bf_task.c functions.h structures.h my-stdio.h my-stdarg.h \
X    bytecodes.h bf_register.h list.h tasks.h execute.h config.h opcode.h \
X    program.h 
X***************
X*** 345,347 ****
X--- 350,355 ----
X  vector.po : vector.c vector.h opcode.h code_elt.h my-stdarg.h my-string.h \
X    structures.h my-stdio.h bytecodes.h 
X  version.po : version.c version.h 
X+ regerror.po : regerror.c 
X+ regexp.po : regexp.c regexp.h regmagic.h 
X+ regsub.po : regsub.c regexp.h regmagic.h 
XOnly in gnoo: REGEXP
Xdiff -c moo/bf_str_list.c gnoo/bf_str_list.c
X*** moo/bf_str_list.c	Fri Aug  9 13:41:38 1991
X--- gnoo/bf_str_list.c	Mon Jan 27 17:21:32 1992
X***************
X*** 3,9 ****
X--- 3,13 ----
X  #include "utils.h" /* strsub, strindex, strrindex */
X  #include "random.h" /* RANDOM() in crypt */
X  #include "my-string.h" /* strlen, strcmp */
X+ /* CWL include for regular expression */
X+ #include "regexp.h"
X+ #include "streams.h"
X  
X+ 
X  /* crypt */
X  extern const char  *crypt(const char *, const char *); /* BSDism */
X  
X***************
X*** 115,120 ****
X--- 119,170 ----
X    return make_var_pack(r);
X  }
X  
X+ /* CWL bf_listassoc additions */
X+ 
X+ static package
X+ bf_listiassoc(Var arglist, Byte next, void *vdata, Parse_Info *pi)
X+ {
X+   Var r;
X+   int index = 1;
X+ 
X+   r.type = TYPE_NUM;
X+   if (arglist.v.list[0].v.num == 3)
X+     index = arglist.v.list[3].v.num;
X+ 
X+   if (index<1) {
X+     free_var(arglist);
X+     return make_error_pack(E_RANGE);
X+   }
X+ 
X+   r.v.num = listiassoc(arglist.v.list[1],arglist.v.list[2],index);
X+ 
X+   free_var(arglist);
X+   return make_var_pack(r);
X+ } /* end listiassoc */
X+ 
X+ 
X+ static package
X+ bf_listassoc(Var arglist, Byte next, void *vdata, Parse_Info *pi)
X+ {
X+   Var r;
X+   int index = 1;
X+ 
X+   if (arglist.v.list[0].v.num==3)
X+     index = arglist.v.list[3].v.num;
X+ 
X+   if (index<1) {
X+     free_var(arglist);
X+     return make_error_pack(E_RANGE);
X+   }
X+ 
X+   r = listassoc(arglist.v.list[1], arglist.v.list[2], index);
X+ 
X+   free_var(arglist);
X+   return make_var_pack(r);
X+ } /* end CWL bf_listassoc */
X+ 
X+ 
X+ 
X  /* 5 functions specific to str */
X  
X  static package
X***************
X*** 157,163 ****
X--- 207,279 ----
X    return make_var_pack(r);
X  }
X  
X+ /* CWL regular expression parse */
X  static package
X+   bf_regexp(Var arglist, Byte next, void *vdata, Parse_Info *pi)
X+ {
X+   /* regexp(string1, string2) */
X+   Var r;
X+   regexp *reg;
X+   int case_matters = 0;
X+   extern void free();
X+ 
X+   if (arglist.v.list[0].v.num == 3)
X+     case_matters = arglist.v.list[3].v.num;
X+   r.type = TYPE_NUM;
X+ 
X+   reg = regcomp(arglist.v.list[1].v.str);
X+   if (reg) {
X+     r.v.num = regexec(reg, arglist.v.list[2].v.str,case_matters);
X+     free(reg);
X+   }
X+   else {
X+     r.v.num = 0;
X+   }
X+   free_var(arglist);
X+   return make_var_pack(r);
X+ } /* end CWL bf_regexp */
X+ 
X+ /* CWL regular expression sub */
X+ static package
X+   bf_regsub(Var arglist, Byte next, void *vdata, Parse_Info *pi)
X+ {
X+   Var r;
X+   regexp *reg;
X+   Stream *astream;
X+   int case_matters = 0;
X+   extern void free();
X+ 
X+   if (arglist.v.list[0].v.num == 4)
X+     case_matters = arglist.v.list[4].v.num;
X+   r.type = TYPE_STR;
X+   reg = regcomp(arglist.v.list[1].v.str);
X+   if (reg) {
X+ 
X+     if (regexec(reg, arglist.v.list[2].v.str,case_matters)) {
X+ 
X+         astream = new_stream(512);
X+         regsub(reg, arglist.v.list[3].v.str, astream);
X+         r.v.str = strdup(stream_contents(astream));
X+ 	free_stream(astream);
X+     }
X+ 
X+     else { /* no regular expression found */
X+       r.v.str = strdup("");
X+     } /* end if regexec else */
X+ 
X+     free(reg); /* Clean up some */
X+   } /* end if reg */
X+ 
X+   else {
X+     r.v.str = strdup("");
X+   } /* end if reg else */
X+ 
X+   free_var(arglist);
X+   return make_var_pack(r);
X+ } /* end CWL bf_regsub */
X+ 
X+ 
X+ static package
X    bf_strcmp(Var arglist, Byte next, void *vdata, Parse_Info *pi)
X  { /* (string1, string2) */
X    Var r;
X***************
X*** 230,235 ****
X--- 346,360 ----
X      = {"strcmp", 2, 2, {TYPE_STR, TYPE_STR}, bf_strcmp};
X    static struct bft_entry bft12 
X      = {"strsub", 3, 4, {TYPE_STR, TYPE_STR, TYPE_STR, TYPE_NUM}, bf_strsub};
X+   /* CWL regexp additions */
X+   static struct bft_entry bft13
X+     = {"regexp", 2, 3, {TYPE_STR, TYPE_STR, TYPE_NUM}, bf_regexp};
X+   static struct bft_entry bft14
X+     = {"regsub", 3, 4, {TYPE_STR, TYPE_STR, TYPE_STR, TYPE_NUM}, bf_regsub};
X+   static struct bft_entry bft15
X+     = {"listassoc", 2, 3, {TYPE_ANY, TYPE_LIST, TYPE_NUM}, bf_listassoc};
X+   static struct bft_entry bft16
X+     = {"listiassoc", 2, 3, {TYPE_ANY, TYPE_LIST, TYPE_NUM}, bf_listiassoc};
X  
X    register_function(bft1);
X    register_function(bft2);
X***************
X*** 243,246 ****
X--- 368,376 ----
X    register_function(bft10);
X    register_function(bft11);
X    register_function(bft12);
X+   /* CWL regexp additions */
X+   register_function(bft13);
X+   register_function(bft14);
X+   register_function(bft15);
X+   register_function(bft16);
X  }
Xdiff -c moo/config.h gnoo/config.h
X*** moo/config.h	Mon Nov 18 16:15:25 1991
X--- gnoo/config.h	Sat Jan 25 11:33:29 1992
X***************
X*** 7,18 ****
X  #define MAX_VERB_DEPTH		50	/* max. number of nested verb calls */
X  
X  				/* max. number of eval() calls */
X! #define FG_TICKS		30000	/* ... foreground tasks */
X! #define BG_TICKS		15000	/* ... background tasks */
X  
X  				/* how long in real time it can run */
X! #define FG_SECONDS		15	/* ... foreground tasks */
X! #define BG_SECONDS		5	/* ... background tasks */
X  
X  /* Objid on which several magic properties are to be found. */
X  #define SYSTEM_OBJECT 0
X--- 7,18 ----
X  #define MAX_VERB_DEPTH		50	/* max. number of nested verb calls */
X  
X  				/* max. number of eval() calls */
X! #define FG_TICKS		90000 /*30000*/	/* ... foreground tasks */
X! #define BG_TICKS		45000 /*15000*/	/* ... background tasks */
X  
X  				/* how long in real time it can run */
X! #define FG_SECONDS		45 /*15*/	/* ... foreground tasks */
X! #define BG_SECONDS		15 /*5*/	/* ... background tasks */
X  
X  /* Objid on which several magic properties are to be found. */
X  #define SYSTEM_OBJECT 0
Xdiff -c moo/list.c gnoo/list.c
X*** moo/list.c	Sun Aug  4 15:29:57 1991
X--- gnoo/list.c	Mon Jan 27 17:22:44 1992
X***************
X*** 148,153 ****
X--- 148,187 ----
X      }
X  }
X  
X+ /* CWL assoc addition */
X+ Var
X+ listassoc(Var vtarget, Var vlist, int vindex)
X+ {
X+   int i;
X+ 
X+   for (i=1; i<=vlist.v.list[0].v.num; i++) {
X+     if (vlist.v.list[i].type == TYPE_LIST &&
X+ 	vlist.v.list[i].v.list[0].v.num >= vindex &&
X+ 	equality(vlist.v.list[i].v.list[vindex], vtarget)) {
X+        
X+        return (vardup(vlist.v.list[i]));
X+     }
X+   }
X+   return (new_list(0));
X+ } /* end CWL listassoc */
X+ 
X+ int
X+ listiassoc(Var vtarget, Var vlist, int vindex)
X+ { 
X+   int i;
X+ 
X+   for (i=1; i<=vlist.v.list[0].v.num; i++) {
X+     if (vlist.v.list[i].type == TYPE_LIST &&
X+         vlist.v.list[i].v.list[0].v.num >= vindex &&
X+         equality(vlist.v.list[i].v.list[vindex], vtarget)) {
X+        
X+        return i;
X+     }      
X+   } 
X+   return 0;
X+ } /* end CWL listiassoc */
X+ 
X+ 
X  Var
X  substr(Var str, int lower, int upper)
X  {
Xdiff -c moo/list.h gnoo/list.h
X*** moo/list.h	Sun Aug  4 15:27:31 1991
X--- gnoo/list.h	Mon Jan 27 17:19:17 1992
X***************
X*** 12,14 ****
X--- 12,17 ----
X  extern Var  substr(Var str, int lower, int upper);
X  extern Var  strget(Var str, Var i);
X  extern Var  new_list(int size);
X+ /* CWL list assoc additions */
X+ extern Var  listassoc(Var vtarget, Var vlist, int vindex);
X+ extern int  listiassoc(Var vtarget, Var vlist, int vindex);
XOnly in gnoo: list:assoc
XOnly in gnoo: reg
XOnly in gnoo: regerror.c
XOnly in gnoo: regexp.3
XOnly in gnoo: regexp.c
XOnly in gnoo: regexp.c.orig
XOnly in gnoo: regexp.h
XOnly in gnoo: regmagic.h
XOnly in gnoo: regsub.c
XOnly in gnoo: strcmp.grep
Xdiff -c moo/utils.c gnoo/utils.c
X*** moo/utils.c	Tue Aug 20 18:15:15 1991
X--- gnoo/utils.c	Sun Jan 26 02:10:56 1992
X***************
X*** 33,38 ****
X--- 33,56 ----
X  \340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\
X  \360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377";
X  
X+ 
X+ char *
X+ mystrcasechr(register char *s, register char t) /* CWL */
X+ {
X+   register char *c = cmap;
X+   register char *sp;
X+   register char ct;
X+ 
X+   sp = s;
X+   ct = c[t];
X+   while (*sp) {
X+     if (c[*sp]==ct)
X+       return sp;
X+     sp++;
X+   }
X+   return NULL;
X+ } /* end CWL */
X+ 
X  #ifndef STRCASE
X  int
X  mystrcasecmp(register const char *s, register const char *t)
Xdiff -c moo/version.c gnoo/version.c
X*** moo/version.c	Thu Dec  5 18:55:20 1991
X--- gnoo/version.c	Fri Jan 24 17:32:05 1992
X***************
X*** 22,25 ****
X  
X  #include "version.h"
X  
X! const char     *server_version = "1.5.9";
X--- 22,25 ----
X  
X  #include "version.h"
X  
X! const char     *server_version = "1.5.9r";
END_OF_FILE
if test 15669 -ne `wc -c <'moo.patch'`; then
    echo shar: \"'moo.patch'\" unpacked with wrong size!
fi
# end of 'moo.patch'
fi
if test -f 'regerror.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regerror.c'\"
else
echo shar: Extracting \"'regerror.c'\" \(260 characters\)
sed "s/^X//" >'regerror.c' <<'END_OF_FILE'
X#include "regexp.h" /* CWL */
X#include <stdio.h>
X
Xvoid
Xregerror(s)
Xconst char *s;
X{
X#ifdef ERRAVAIL
X	error("regexp: %s", s);
X#else
X/*
X	fprintf(stderr, "regexp(3): %s\n", s);
X	exit(1);
X*/
X	return;	  /* let std. egrep handle errors */
X#endif
X	/* NOTREACHED */
X}
END_OF_FILE
if test 260 -ne `wc -c <'regerror.c'`; then
    echo shar: \"'regerror.c'\" unpacked with wrong size!
fi
# end of 'regerror.c'
fi
if test -f 'regexp.3' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regexp.3'\"
else
echo shar: Extracting \"'regexp.3'\" \(8935 characters\)
sed "s/^X//" >'regexp.3' <<'END_OF_FILE'
X.\" Copyright 1991 The Regents of the University of California.
X.\" All rights reserved.
X.\"
X.\" Redistribution and use in source and binary forms, with or without
X.\" modification, are permitted provided that the following conditions
X.\" are met:
X.\" 1. Redistributions of source code must retain the above copyright
X.\"    notice, this list of conditions and the following disclaimer.
X.\" 2. Redistributions in binary form must reproduce the above copyright
X.\"    notice, this list of conditions and the following disclaimer in the
X.\"    documentation and/or other materials provided with the distribution.
X.\" 3. All advertising materials mentioning features or use of this software
X.\"    must display the following acknowledgement:
X.\"	This product includes software developed by the University of
X.\"	California, Berkeley and its contributors.
X.\" 4. Neither the name of the University nor the names of its contributors
X.\"    may be used to endorse or promote products derived from this software
X.\"    without specific prior written permission.
X.\"
X.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
X.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
X.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
X.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
X.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
X.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
X.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
X.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
X.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
X.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
X.\" SUCH DAMAGE.
X.\"
X.\"     @(#)regexp.3	5.2 (Berkeley) 4/20/91
X.\"
X.Dd April 20, 1991
X.Dt REGEXP 3
X.Os
X.Sh NAME
X.Nm regcomp ,
X.Nm regexec ,
X.Nm regsub ,
X.Nm regerror
X.Nd regular expression handlers
X.Sh SYNOPSIS
X.Fd #include <regexp.h>
X.Ft regexp *
X.Fn regcomp "const char *exp"
X.Ft int
X.Fn regexec "const regexp *prog" "const char *string"
X.Ft void
X.Fn regsub "const regexp *prog" "const char *source" "char *dest"
X.Sh DESCRIPTION
XThe
X.Fn regcomp ,
X.Fn regexec ,
X.Fn regsub ,
Xand
X.Fn regerror
Xfunctions
Ximplement
X.Xr egrep 1 Ns -style
Xregular expressions and supporting facilities.
X.Pp
XThe
X.Fn regcomp
Xfunction
Xcompiles a regular expression into a structure of type
X.Xr regexp ,
Xand returns a pointer to it.
XThe space has been allocated using
X.Xr malloc 3
Xand may be released by
X.Xr free .
X.Pp
XThe
X.Fn regexec
Xfunction
Xmatches a
X.Dv NUL Ns -terminated
X.Fa string
Xagainst the compiled regular expression
Xin
X.Fa prog .
XIt returns 1 for success and 0 for failure, and adjusts the contents of
X.Fa prog Ns 's
X.Em startp
Xand
X.Em endp
X(see below) accordingly.
X.Pp
XThe members of a
X.Xr regexp
Xstructure include at least the following (not necessarily in order):
X.Bd -literal -offset indent
Xchar *startp[NSUBEXP];
Xchar *endp[NSUBEXP];
X.Ed
X.Pp
Xwhere
X.Dv NSUBEXP
Xis defined (as 10) in the header file.
XOnce a successful
X.Fn regexec
Xhas been done using the
X.Fn regexp ,
Xeach
X.Em startp Ns - Em endp
Xpair describes one substring
Xwithin the
X.Fa string ,
Xwith the
X.Em startp
Xpointing to the first character of the substring and
Xthe
X.Em endp
Xpointing to the first character following the substring.
XThe 0th substring is the substring of
X.Fa string
Xthat matched the whole
Xregular expression.
XThe others are those substrings that matched parenthesized expressions
Xwithin the regular expression, with parenthesized expressions numbered
Xin left-to-right order of their opening parentheses.
X.Pp
XThe
X.Fn regsub
Xfunction
Xcopies
X.Fa source
Xto
X.Fa dest ,
Xmaking substitutions according to the
Xmost recent
X.Fn regexec
Xperformed using
X.Fa prog .
XEach instance of `&' in
X.Fa source
Xis replaced by the substring
Xindicated by
X.Em startp Ns Bq
Xand
X.Em endp Ns Bq .
XEach instance of
X.Sq \e Ns Em n ,
Xwhere
X.Em n
Xis a digit, is replaced by
Xthe substring indicated by
X.Em startp Ns Bq Em n
Xand
X.Em endp Ns Bq Em n .
XTo get a literal `&' or
X.Sq \e Ns Em n
Xinto
X.Fa dest ,
Xprefix it with `\e';
Xto get a literal `\e' preceding `&' or
X.Sq \e Ns Em n ,
Xprefix it with
Xanother `\e'.
X.Pp
XThe
X.Fn regerror
Xfunction
Xis called whenever an error is detected in
X.Fn regcomp ,
X.Fn regexec ,
Xor
X.Fn regsub .
XThe default
X.Fn regerror
Xwrites the string
X.Fa msg ,
Xwith a suitable indicator of origin,
Xon the standard
Xerror output
Xand invokes
X.Xr exit 2 .
XThe
X.Fn regerror
Xfunction
Xcan be replaced by the user if other actions are desirable.
X.Sh REGULAR EXPRESSION SYNTAX
XA regular expression is zero or more
X.Em branches ,
Xseparated by `|'.
XIt matches anything that matches one of the branches.
X.Pp
XA branch is zero or more
X.Em pieces ,
Xconcatenated.
XIt matches a match for the first, followed by a match for the second, etc.
X.Pp
XA piece is an
X.Em atom
Xpossibly followed by `*', `+', or `?'.
XAn atom followed by `*' matches a sequence of 0 or more matches of the atom.
XAn atom followed by `+' matches a sequence of 1 or more matches of the atom.
XAn atom followed by `?' matches a match of the atom, or the null string.
X.Pp
XAn atom is a regular expression in parentheses (matching a match for the
Xregular expression), a
X.Em range
X(see below), `.'
X(matching any single character), `^' (matching the null string at the
Xbeginning of the input string), `$' (matching the null string at the
Xend of the input string), a `\e' followed by a single character (matching
Xthat character), or a single character with no other significance
X(matching that character).
X.Pp
XA
X.Em range
Xis a sequence of characters enclosed in `[]'.
XIt normally matches any single character from the sequence.
XIf the sequence begins with `^',
Xit matches any single character
X.Em not
Xfrom the rest of the sequence.
XIf two characters in the sequence are separated by `\-', this is shorthand
Xfor the full list of
X.Tn ASCII
Xcharacters between them
X(e.g. `[0-9]' matches any decimal digit).
XTo include a literal `]' in the sequence, make it the first character
X(following a possible `^').
XTo include a literal `\-', make it the first or last character.
X.Sh AMBIGUITY
XIf a regular expression could match two different parts of the input string,
Xit will match the one which begins earliest.
XIf both begin in the same place but match different lengths, or match
Xthe same length in different ways, life gets messier, as follows.
X.Pp
XIn general, the possibilities in a list of branches are considered in
Xleft-to-right order, the possibilities for `*', `+', and `?' are
Xconsidered longest-first, nested constructs are considered from the
Xoutermost in, and concatenated constructs are considered leftmost-first.
XThe match that will be chosen is the one that uses the earliest
Xpossibility in the first choice that has to be made.
XIf there is more than one choice, the next will be made in the same manner
X(earliest possibility) subject to the decision on the first choice.
XAnd so forth.
X.Pp
XFor example,
X.Sq Li (ab|a)b*c
Xcould match
X`abc' in one of two ways.
XThe first choice is between `ab' and `a'; since `ab' is earlier, and does
Xlead to a successful overall match, it is chosen.
XSince the `b' is already spoken for,
Xthe `b*' must match its last possibility\(emthe empty string\(emsince
Xit must respect the earlier choice.
X.Pp
XIn the particular case where no `|'s are present and there is only one
X`*', `+', or `?', the net effect is that the longest possible
Xmatch will be chosen.
XSo
X.Sq Li ab* ,
Xpresented with `xabbbby', will match `abbbb'.
XNote that if
X.Sq Li ab* ,
Xis tried against `xabyabbbz', it
Xwill match `ab' just after `x', due to the begins-earliest rule.
X(In effect, the decision on where to start the match is the first choice
Xto be made, hence subsequent choices must respect it even if this leads them
Xto less-preferred alternatives.)
X.Sh RETURN VALUES
XThe
X.Fn regcomp
Xfunction
Xreturns
X.Dv NULL
Xfor a failure
X.Pf ( Fn regerror
Xpermitting),
Xwhere failures are syntax errors, exceeding implementation limits,
Xor applying `+' or `*' to a possibly-null operand.
X.Sh SEE ALSO
X.Xr ed 1 ,
X.Xr ex 1 ,
X.Xr expr 1 ,
X.Xr egrep 1 ,
X.Xr fgrep 1 ,
X.Xr grep 1 ,
X.Xr regex 3
X.Sh HISTORY
XBoth code and manual page for
X.Fn regcomp ,
X.Fn regexec ,
X.Fn regsub ,
Xand
X.Fn regerror
Xwere written at the University of Toronto
Xand appeared in
X.Bx 4.3 tahoe .
XThey are intended to be compatible with the Bell V8
X.Xr regexp 3 ,
Xbut are not derived from Bell code.
X.Sh BUGS
XEmpty branches and empty regular expressions are not portable to V8.
X.Pp
XThe restriction against
Xapplying `*' or `+' to a possibly-null operand is an artifact of the
Xsimplistic implementation.
X.Pp
XDoes not support
X.Xr egrep Ns 's
Xnewline-separated branches;
Xneither does the V8
X.Xr regexp 3 ,
Xthough.
X.Pp
XDue to emphasis on
Xcompactness and simplicity,
Xit's not strikingly fast.
XIt does give special attention to handling simple cases quickly.
END_OF_FILE
if test 8935 -ne `wc -c <'regexp.3'`; then
    echo shar: \"'regexp.3'\" unpacked with wrong size!
fi
# end of 'regexp.3'
fi
if test -f 'regexp.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regexp.c'\"
else
echo shar: Extracting \"'regexp.c'\" \(31972 characters\)
sed "s/^X//" >'regexp.c' <<'END_OF_FILE'
X/*
X * regcomp and regexec -- regsub and regerror are elsewhere
X *
X *	Copyright (c) 1986 by University of Toronto.
X *	Written by Henry Spencer.  Not derived from licensed software.
X *
X *	Permission is granted to anyone to use this software for any
X *	purpose on any computer system, and to redistribute it freely,
X *	subject to the following restrictions:
X *
X *	1. The author is not responsible for the consequences of use of
X *		this software, no matter how awful, even if they arise
X *		from defects in it.
X *
X *	2. The origin of this software must not be misrepresented, either
X *		by explicit claim or by omission.
X *
X *	3. Altered versions must be plainly marked as such, and must not
X *		be misrepresented as being the original software.
X *** THIS IS AN ALTERED VERSION.  It was altered by John Gilmore,
X *** hoptoad!gnu, on 27 Dec 1986, to add \n as an alternative to |
X *** to assist in implementing egrep.
X *** THIS IS AN ALTERED VERSION.  It was altered by John Gilmore,
X *** hoptoad!gnu, on 27 Dec 1986, to add \< and \> for word-matching
X *** as in BSD grep and ex.
X *** THIS IS AN ALTERED VERSION.  It was altered by John Gilmore,
X *** hoptoad!gnu, on 28 Dec 1986, to optimize characters quoted with \.
X *** THIS IS AN ALTERED VERSION.  It was altered by James A. Woods,
X *** ames!jaw, on 19 June 1987, to quash a regcomp() redundancy.
X *** THIS CODE HAS BEEN CHANGED TO WORK WITH MOO by Clay Luther,
X *** January 24, 1992.
X *
X * Beware that some of this code is subtly aware of the way operator
X * precedence is structured in regular expressions.  Serious changes in
X * regular-expression syntax might require a total rethink.
X */
X
X/* Changes by CWL for moo */
X
X#include "regexp.h" /* CWL */
X#include <stdio.h>
X#include <ctype.h>
X#include <stdlib.h>
X#include <string.h>
X#include "regmagic.h"
X#include <ctype.h> /* CWL */
X
X/*
X * The "internal use only" fields in regexp.h are present to pass info from
X * compile to execute that permits the execute phase to run lots faster on
X * simple cases.  They are:
X *
X * regstart	char that must begin a match; '\0' if none obvious
X * reganch	is the match anchored (at beginning-of-line only)?
X * regmust	string (pointer into program) that match must include, or NULL
X * regmlen	length of regmust string
X *
X * Regstart and reganch permit very fast decisions on suitable starting points
X * for a match, cutting down the work a lot.  Regmust permits fast rejection
X * of lines that cannot possibly match.  The regmust tests are costly enough
X * that regcomp() supplies a regmust only if the r.e. contains something
X * potentially expensive (at present, the only such thing detected is * or +
X * at the start of the r.e., which can involve a lot of backup).  Regmlen is
X * supplied because the test in regexec() needs it and regcomp() is computing
X * it anyway.
X */
X
X/*
X * Structure for regexp "program".  This is essentially a linear encoding
X * of a nondeterministic finite-state machine (aka syntax charts or
X * "railroad normal form" in parsing technology).  Each node is an opcode
X * plus a "next" pointer, possibly plus an operand.  "Next" pointers of
X * all nodes except BRANCH implement concatenation; a "next" pointer with
X * a BRANCH on both ends of it is connecting two alternatives.  (Here we
X * have one of the subtle syntax dependencies:  an individual BRANCH (as
X * opposed to a collection of them) is never concatenated with anything
X * because of operator precedence.)  The operand of some types of node is
X * a literal string; for others, it is a node leading into a sub-FSM.  In
X * particular, the operand of a BRANCH node is the first node of the branch.
X * (NB this is *not* a tree structure:  the tail of the branch connects
X * to the thing following the set of BRANCHes.)  The opcodes are:
X */
X
X/* definition	number	opnd?	meaning */
X#define	END	0	/* no	End of program. */
X#define	BOL	1	/* no	Match "" at beginning of line. */
X#define	EOL	2	/* no	Match "" at end of line. */
X#define	ANY	3	/* no	Match any one character. */
X#define	ANYOF	4	/* str	Match any character in this string. */
X#define	ANYBUT	5	/* str	Match any character not in this string. */
X#define	BRANCH	6	/* node	Match this alternative, or the next... */
X#define	BACK	7	/* no	Match "", "next" ptr points backward. */
X#define	EXACTLY	8	/* str	Match this string. */
X#define	NOTHING	9	/* no	Match empty string. */
X#define	STAR	10	/* node	Match this (simple) thing 0 or more times. */
X#define	PLUS	11	/* node	Match this (simple) thing 1 or more times. */
X#define	WORDA	12	/* no	Match "" at wordchar, where prev is nonword */
X#define	WORDZ	13	/* no	Match "" at nonwordchar, where prev is word */
X#define	OPEN	20	/* no	Mark this point in input as start of #n. */
X			/*	OPEN+1 is number 1, etc. */
X#define	CLOSE	30	/* no	Analogous to OPEN. */
X
X/*
X * Opcode notes:
X *
X * BRANCH	The set of branches constituting a single choice are hooked
X *		together with their "next" pointers, since precedence prevents
X *		anything being concatenated to any individual branch.  The
X *		"next" pointer of the last BRANCH in a choice points to the
X *		thing following the whole choice.  This is also where the
X *		final "next" pointer of each individual branch points; each
X *		branch starts with the operand node of a BRANCH node.
X *
X * BACK		Normal "next" pointers all implicitly point forward; BACK
X *		exists to make loop structures possible.
X *
X * STAR,PLUS	'?', and complex '*' and '+', are implemented as circular
X *		BRANCH structures using BACK.  Simple cases (one character
X *		per match) are implemented with STAR and PLUS for speed
X *		and to minimize recursive plunges.
X *
X * OPEN,CLOSE	...are numbered at compile time.
X */
X
X/*
X * A node is one char of opcode followed by two chars of "next" pointer.
X * "Next" pointers are stored as two 8-bit pieces, high order first.  The
X * value is a positive offset from the opcode of the node containing it.
X * An operand, if any, simply follows the node.  (Note that much of the
X * code generation knows about this implicit relationship.)
X *
X * Using two bytes for the "next" pointer is vast overkill for most things,
X * but allows patterns to get big without disasters.
X */
X#define	OP(p)	(*(p))
X#define	NEXT(p)	(((*((p)+1)&0377)<<8) + (*((p)+2)&0377))
X#define	OPERAND(p)	((p) + 3)
X
X/*
X * See regmagic.h for one further detail of program structure.
X */
X
X
X/*
X * Utility definitions.
X */
X#ifndef CHARBITS
X#define	UCHARAT(p)	((int)*(unsigned char *)(p))
X#else
X#define	UCHARAT(p)	((int)*(p)&CHARBITS)
X#endif
X
X#define	FAIL(m)	{ regerror(m); return(NULL); }
X#define	ISMULT(c)	((c) == '*' || (c) == '+' || (c) == '?')
X
X/*
X * Flags to be passed up and down.
X */
X#define	HASWIDTH	01	/* Known never to match null string. */
X#define	SIMPLE		02	/* Simple enough to be STAR/PLUS operand. */
X#define	SPSTART		04	/* Starts with * or +. */
X#define	WORST		0	/* Worst case. */
X
X/*
X * Global work variables for regcomp().
X */
Xstatic char *regparse;		/* Input-scan pointer. */
Xstatic int regnpar;		/* () count. */
Xstatic char regdummy;
Xstatic char *regcode;		/* Code-emit pointer; &regdummy = don't. */
Xstatic long regsize;		/* Code size. */
X
X/*
X * Forward declarations for regcomp()'s friends.
X */
X#ifndef STATIC
X#define	STATIC	static
X#endif
XSTATIC char *reg();
XSTATIC char *regbranch();
XSTATIC char *regpiece();
XSTATIC char *regatom();
XSTATIC char *regnode();
XSTATIC char *regnext();
XSTATIC void regc();
XSTATIC void reginsert();
XSTATIC void regtail();
XSTATIC void regoptail();
X#ifdef STRCSPN
XSTATIC int strcspn();
X#endif
X
X/*
X - regcomp - compile a regular expression into internal code
X *
X * We can't allocate space until we know how big the compiled form will be,
X * but we can't compile it (and thus know how big it is) until we've got a
X * place to put the code.  So we cheat:  we compile it twice, once with code
X * generation turned off and size counting turned on, and once "for real".
X * This also means that we don't allocate space until we are sure that the
X * thing really will compile successfully, and we never have to move the
X * code and thus invalidate pointers into it.  (Note that it has to be in
X * one piece because free() must be able to free it all.)
X *
X * Beware that the optimization-preparation code in here knows about some
X * of the structure of the compiled regexp.
X */
Xregexp *
Xregcomp(exp)
Xconst char *exp;
X{
X	register regexp *r;
X	register char *scan;
X	register char *longest;
X	register int len;
X	int flags;
X
X	if (exp == NULL)
X		FAIL("NULL argument");
X
X	/* First pass: determine size, legality. */
X#ifdef notdef
X	if (exp[0] == '.' && exp[1] == '*') exp += 2;  /* aid grep */
X#endif
X	regparse = (char *)exp;
X	regnpar = 1;
X	regsize = 0L;
X	regcode = &regdummy;
X	regc(MAGIC);
X	if (reg(0, &flags) == NULL)
X		return(NULL);
X
X	/* Small enough for pointer-storage convention? */
X	if (regsize >= 32767L)		/* Probably could be 65535L. */
X		FAIL("regexp too big");
X
X	/* Allocate space. */
X	r = (regexp *)malloc(sizeof(regexp) + (unsigned)regsize);
X	if (r == NULL)
X		FAIL("out of space");
X
X	/* Second pass: emit code. */
X	regparse = (char *)exp;
X	regnpar = 1;
X	regcode = r->program;
X	regc(MAGIC);
X	if (reg(0, &flags) == NULL)
X		return(NULL);
X
X	/* Dig out information for optimizations. */
X	r->regstart = '\0';	/* Worst-case defaults. */
X	r->reganch = 0;
X	r->regmust = NULL;
X	r->regmlen = 0;
X	scan = r->program+1;			/* First BRANCH. */
X	if (OP(regnext(scan)) == END) {		/* Only one top-level choice. */
X		scan = OPERAND(scan);
X
X		/* Starting-point info. */
X		if (OP(scan) == EXACTLY)
X			r->regstart = *OPERAND(scan);
X		else if (OP(scan) == BOL)
X			r->reganch++;
X
X		/*
X		 * If there's something expensive in the r.e., find the
X		 * longest literal string that must appear and make it the
X		 * regmust.  Resolve ties in favor of later strings, since
X		 * the regstart check works with the beginning of the r.e.
X		 * and avoiding duplication strengthens checking.  Not a
X		 * strong reason, but sufficient in the absence of others.
X		 */
X		if (flags&SPSTART) {
X			longest = NULL;
X			len = 0;
X			for (; scan != NULL; scan = regnext(scan))
X				if (OP(scan) == EXACTLY && strlen(OPERAND(scan)) >= len) {
X					longest = OPERAND(scan);
X					len = strlen(OPERAND(scan));
X				}
X			r->regmust = longest;
X			r->regmlen = len;
X		}
X	}
X
X	return(r);
X}
X
X/*
X - reg - regular expression, i.e. main body or parenthesized thing
X *
X * Caller must absorb opening parenthesis.
X *
X * Combining parenthesis handling with the base level of regular expression
X * is a trifle forced, but the need to tie the tails of the branches to what
X * follows makes it hard to avoid.
X */
Xstatic char *
Xreg(paren, flagp)
Xint paren;			/* Parenthesized? */
Xint *flagp;
X{
X	register char *ret;
X	register char *br;
X	register char *ender;
X	register int parno = 0;
X	int flags;
X
X	*flagp = HASWIDTH;	/* Tentatively. */
X
X	/* Make an OPEN node, if parenthesized. */
X	if (paren) {
X		if (regnpar >= NSUBEXP)
X			FAIL("too many ()");
X		parno = regnpar;
X		regnpar++;
X		ret = regnode(OPEN+parno);
X	} else
X		ret = NULL;
X
X	/* Pick up the branches, linking them together. */
X	br = regbranch(&flags);
X	if (br == NULL)
X		return(NULL);
X	if (ret != NULL)
X		regtail(ret, br);	/* OPEN -> first. */
X	else
X		ret = br;
X	if (!(flags&HASWIDTH))
X		*flagp &= ~HASWIDTH;
X	*flagp |= flags&SPSTART;
X	while (*regparse == '|' || *regparse == '\n') {
X		regparse++;
X		br = regbranch(&flags);
X		if (br == NULL)
X			return(NULL);
X		regtail(ret, br);	/* BRANCH -> BRANCH. */
X		if (!(flags&HASWIDTH))
X			*flagp &= ~HASWIDTH;
X		*flagp |= flags&SPSTART;
X	}
X
X	/* Make a closing node, and hook it on the end. */
X	ender = regnode((paren) ? CLOSE+parno : END);	
X	regtail(ret, ender);
X
X	/* Hook the tails of the branches to the closing node. */
X	for (br = ret; br != NULL; br = regnext(br))
X		regoptail(br, ender);
X
X	/* Check for proper termination. */
X	if (paren && *regparse++ != ')') {
X		FAIL("unmatched ()");
X	} else if (!paren && *regparse != '\0') {
X		if (*regparse == ')') {
X			FAIL("unmatched ()");
X		} else
X			FAIL("junk on end");	/* "Can't happen". */
X		/* NOTREACHED */
X	}
X
X	return(ret);
X}
X
X/*
X - regbranch - one alternative of an | operator
X *
X * Implements the concatenation operator.
X */
Xstatic char *
Xregbranch(flagp)
Xint *flagp;
X{
X	register char *ret;
X	register char *chain;
X	register char *latest;
X	int flags;
X
X	*flagp = WORST;		/* Tentatively. */
X
X	ret = regnode(BRANCH);
X	chain = NULL;
X	while (*regparse != '\0' && *regparse != ')' &&
X	       *regparse != '\n' && *regparse != '|') {
X		latest = regpiece(&flags);
X		if (latest == NULL)
X			return(NULL);
X		*flagp |= flags&HASWIDTH;
X		if (chain == NULL)	/* First piece. */
X			*flagp |= flags&SPSTART;
X		else
X			regtail(chain, latest);
X		chain = latest;
X	}
X	if (chain == NULL)	/* Loop ran zero times. */
X		(void) regnode(NOTHING);
X
X	return(ret);
X}
X
X/*
X - regpiece - something followed by possible [*+?]
X *
X * Note that the branching code sequences used for ? and the general cases
X * of * and + are somewhat optimized:  they use the same NOTHING node as
X * both the endmarker for their branch list and the body of the last branch.
X * It might seem that this node could be dispensed with entirely, but the
X * endmarker role is not redundant.
X */
Xstatic char *
Xregpiece(flagp)
Xint *flagp;
X{
X	register char *ret;
X	register char op;
X	register char *next;
X	int flags;
X
X	ret = regatom(&flags);
X	if (ret == NULL)
X		return(NULL);
X
X	op = *regparse;
X	if (!ISMULT(op)) {
X		*flagp = flags;
X		return(ret);
X	}
X
X	if (!(flags&HASWIDTH) && op != '?')
X		FAIL("*+ operand could be empty");
X	*flagp = (op != '+') ? (WORST|SPSTART) : (WORST|HASWIDTH);
X
X	if (op == '*' && (flags&SIMPLE))
X		reginsert(STAR, ret);
X	else if (op == '*') {
X		/* Emit x* as (x&|), where & means "self". */
X		reginsert(BRANCH, ret);			/* Either x */
X		regoptail(ret, regnode(BACK));		/* and loop */
X		regoptail(ret, ret);			/* back */
X		regtail(ret, regnode(BRANCH));		/* or */
X		regtail(ret, regnode(NOTHING));		/* null. */
X	} else if (op == '+' && (flags&SIMPLE))
X		reginsert(PLUS, ret);
X	else if (op == '+') {
X		/* Emit x+ as x(&|), where & means "self". */
X		next = regnode(BRANCH);			/* Either */
X		regtail(ret, next);
X		regtail(regnode(BACK), ret);		/* loop back */
X		regtail(next, regnode(BRANCH));		/* or */
X		regtail(ret, regnode(NOTHING));		/* null. */
X	} else if (op == '?') {
X		/* Emit x? as (x|) */
X		reginsert(BRANCH, ret);			/* Either x */
X		regtail(ret, regnode(BRANCH));		/* or */
X		next = regnode(NOTHING);		/* null. */
X		regtail(ret, next);
X		regoptail(ret, next);
X	}
X	regparse++;
X	if (ISMULT(*regparse))
X		FAIL("nested *?+");
X
X	return(ret);
X}
X
X/*
X - regatom - the lowest level
X *
X * Optimization:  gobbles an entire sequence of ordinary characters so that
X * it can turn them into a single node, which is smaller to store and
X * faster to run.  Backslashed characters are exceptions, each becoming a
X * separate node; the code is simpler that way and it's not worth fixing.
X */
Xstatic char *
Xregatom(flagp)
Xint *flagp;
X{
X	register char *ret;
X	int flags;
X
X	*flagp = WORST;		/* Tentatively. */
X
X	switch (*regparse++) {
X	/* FIXME: these chars only have meaning at beg/end of pat? */
X	case '^':
X		ret = regnode(BOL);
X		break;
X	case '$':
X		ret = regnode(EOL);
X		break;
X	case '.':
X		ret = regnode(ANY);
X		*flagp |= HASWIDTH|SIMPLE;
X		break;
X	case '[': {
X			register int class;
X			register int classend;
X
X			if (*regparse == '^') {	/* Complement of range. */
X				ret = regnode(ANYBUT);
X				regparse++;
X			} else
X				ret = regnode(ANYOF);
X			if (*regparse == ']' || *regparse == '-')
X				regc(*regparse++);
X			while (*regparse != '\0' && *regparse != ']') {
X				if (*regparse == '-') {
X					regparse++;
X					if (*regparse == ']' || *regparse == '\0')
X						regc('-');
X					else {
X						class = UCHARAT(regparse-2)+1;
X						classend = UCHARAT(regparse);
X						if (class > classend+1)
X							FAIL("invalid [] range");
X						for (; class <= classend; class++)
X							regc(class);
X						regparse++;
X					}
X				} else
X					regc(*regparse++);
X			}
X			regc('\0');
X			if (*regparse != ']')
X				FAIL("unmatched []");
X			regparse++;
X			*flagp |= HASWIDTH|SIMPLE;
X		}
X		break;
X	case '(':
X		ret = reg(1, &flags);
X		if (ret == NULL)
X			return(NULL);
X		*flagp |= flags&(HASWIDTH|SPSTART);
X		break;
X	case '\0':
X	case '|':
X	case '\n':
X	case ')':
X		FAIL("internal urp");	/* Supposed to be caught earlier. */
X		break;
X	case '?':
X	case '+':
X	case '*':
X		FAIL("?+* follows nothing");
X		break;
X/*CWL	case '\\':*/
X        case '%':
X		switch (*regparse++) {
X		case '\0':
X			FAIL("trailing \\");
X			break;
X		case '<':
X			ret = regnode(WORDA);
X			break;
X		case '>':
X			ret = regnode(WORDZ);
X			break;
X		/* FIXME: Someday handle \1, \2, ... */
X		default:
X			/* Handle general quoted chars in exact-match routine */
X			goto de_fault;
X		}
X		break;
X	de_fault:
X	default:
X		/*
X		 * Encode a string of characters to be matched exactly.
X		 *
X		 * This is a bit tricky due to quoted chars and due to
X		 * '*', '+', and '?' taking the SINGLE char previous
X		 * as their operand.
X		 *
X		 * On entry, the char at regparse[-1] is going to go
X		 * into the string, no matter what it is.  (It could be
X		 * following a \ if we are entered from the '\' case.)
X		 * 
X		 * Basic idea is to pick up a good char in  ch  and
X		 * examine the next char.  If it's *+? then we twiddle.
X		 * If it's \ then we frozzle.  If it's other magic char
X		 * we push  ch  and terminate the string.  If none of the
X		 * above, we push  ch  on the string and go around again.
X		 *
X		 *  regprev  is used to remember where "the current char"
X		 * starts in the string, if due to a *+? we need to back
X		 * up and put the current char in a separate, 1-char, string.
X		 * When  regprev  is NULL,  ch  is the only char in the
X		 * string; this is used in *+? handling, and in setting
X		 * flags |= SIMPLE at the end.
X		 */
X		{
X			char *regprev;
X			register char ch;
X
X			regparse--;			/* Look at cur char */
X			ret = regnode(EXACTLY);
X			for ( regprev = 0 ; ; ) {
X				ch = *regparse++;	/* Get current char */
X				switch (*regparse) {	/* look at next one */
X
X				default:
X					regc(ch);	/* Add cur to string */
X					break;
X
X				case '.': case '[': case '(':
X				case ')': case '|': case '\n':
X				case '$': case '^':
X				case '\0':
X				/* FIXME, $ and ^ should not always be magic */
X				magic:
X					regc(ch);	/* dump cur char */
X					goto done;	/* and we are done */
X
X				case '?': case '+': case '*':
X					if (!regprev) 	/* If just ch in str, */
X						goto magic;	/* use it */
X					/* End mult-char string one early */
X					regparse = regprev; /* Back up parse */
X					goto done;
X
X/*CWL				case '\\':*/
X				case '%':
X					regc(ch);	/* Cur char OK */
X					switch (regparse[1]){ /* Look after \ */
X					case '\0':
X					case '<':
X					case '>':
X					/* FIXME: Someday handle \1, \2, ... */
X						goto done; /* Not quoted */
X					default:
X						/* Backup point is \, scan							 * point is after it. */
X						regprev = regparse;
X						regparse++; 
X						continue;	/* NOT break; */
X					}
X				}
X				regprev = regparse;	/* Set backup point */
X			}
X		done:
X			regc('\0');
X			*flagp |= HASWIDTH;
X			if (!regprev)		/* One char? */
X				*flagp |= SIMPLE;
X		}
X		break;
X	}
X
X	return(ret);
X}
X
X/*
X - regnode - emit a node
X */
Xstatic char *			/* Location. */
Xregnode(op)
Xchar op;
X{
X	register char *ret;
X	register char *ptr;
X
X	ret = regcode;
X	if (ret == &regdummy) {
X		regsize += 3;
X		return(ret);
X	}
X
X	ptr = ret;
X	*ptr++ = op;
X	*ptr++ = '\0';		/* Null "next" pointer. */
X	*ptr++ = '\0';
X	regcode = ptr;
X
X	return(ret);
X}
X
X/*
X - regc - emit (if appropriate) a byte of code
X */
Xstatic void
Xregc(b)
Xchar b;
X{
X	if (regcode != &regdummy)
X		*regcode++ = b;
X	else
X		regsize++;
X}
X
X/*
X - reginsert - insert an operator in front of already-emitted operand
X *
X * Means relocating the operand.
X */
Xstatic void
Xreginsert(op, opnd)
Xchar op;
Xchar *opnd;
X{
X	register char *src;
X	register char *dst;
X	register char *place;
X
X	if (regcode == &regdummy) {
X		regsize += 3;
X		return;
X	}
X
X	src = regcode;
X	regcode += 3;
X	dst = regcode;
X	while (src > opnd)
X		*--dst = *--src;
X
X	place = opnd;		/* Op node, where operand used to be. */
X	*place++ = op;
X	*place++ = '\0';
X	*place++ = '\0';
X}
X
X/*
X - regtail - set the next-pointer at the end of a node chain
X */
Xstatic void
Xregtail(p, val)
Xchar *p;
Xchar *val;
X{
X	register char *scan;
X	register char *temp;
X	register int offset;
X
X	if (p == &regdummy)
X		return;
X
X	/* Find last node. */
X	scan = p;
X	for (;;) {
X		temp = regnext(scan);
X		if (temp == NULL)
X			break;
X		scan = temp;
X	}
X
X	if (OP(scan) == BACK)
X		offset = scan - val;
X	else
X		offset = val - scan;
X	*(scan+1) = (offset>>8)&0377;
X	*(scan+2) = offset&0377;
X}
X
X/*
X - regoptail - regtail on operand of first argument; nop if operandless
X */
Xstatic void
Xregoptail(p, val)
Xchar *p;
Xchar *val;
X{
X	/* "Operandless" and "op != BRANCH" are synonymous in practice. */
X	if (p == NULL || p == &regdummy || OP(p) != BRANCH)
X		return;
X	regtail(OPERAND(p), val);
X}
X
X/*
X * regexec and friends
X */
X
X/*
X * Global work variables for regexec().
X */
Xstatic char *reginput;		/* String-input pointer. */
Xstatic char *regbol;		/* Beginning of input, for ^ check. */
Xstatic char **regstartp;	/* Pointer to startp array. */
Xstatic char **regendp;		/* Ditto for endp. */
Xstatic int case_flag;                /* CWL case sensitivity flag */
X
Xextern int mystrncasecmp();
Xextern char *mystrcasechr();
Xextern char tolower();
X
X#define CASE(c) ((!case_flag) ? tolower((c)) : (c))
X#define STRCHR(s,c) ((case_flag) ? strchr((s),(c)) : \
X	  mystrcasechr((s),(c)))
X#define STRNCMP(s,c,n) ((case_flag) ? strncmp((s),(c),(n)) : \
X         mystrncasecmp((s),(c),(n)))
X
X/*
X * Forwards.
X */
XSTATIC int regtry();
XSTATIC int regmatch();
XSTATIC int regrepeat();
X
X#ifdef DEBUG
Xint regnarrate = 0;
Xvoid regdump();
XSTATIC char *regprop();
X#endif
X
X/*
X - regexec - match a regexp against a string
X */
Xint
Xregexec(prog, string, case_sense)
Xregister const regexp *prog;
Xregister const char *string;
Xregister const int case_sense;
X{
X	register char *s;
X	extern char *strchr();
X
X	/* CWL */
X	case_flag = case_sense;
X	/* Be paranoid... */
X	if (prog == NULL || string == NULL) {
X		regerror("NULL parameter");
X		return(0);
X	}
X
X	/* Check validity of program. */
X	if (UCHARAT(prog->program) != MAGIC) {
X		regerror("corrupted program");
X		return(0);
X	}
X
X	/* If there is a "must appear" string, look for it. */
X	if (prog->regmust != NULL) {
X		s = (char *)string;
X		while ((s = STRCHR(s, prog->regmust[0])) != NULL) {
X			if (STRNCMP(s, prog->regmust, prog->regmlen) == 0)
X				break;	/* Found it. */
X			s++;
X		}
X		if (s == NULL)	/* Not present. */
X			return(0);
X	}
X	/* Mark beginning of line for ^ . */
X	regbol = (char *)string;
X
X	/* Simplest case:  anchored match need be tried only once. */
X	if (prog->reganch)
X		return(regtry(prog, string));
X
X	/* Messy cases:  unanchored match. */
X	s = (char *)string;
X	if (prog->regstart != '\0')
X		/* We know what char it must start with. */
X		while ((s = STRCHR(s, prog->regstart)) != NULL) {
X			if (regtry(prog, s))
X				return(1);
X			s++;
X		}
X	else
X		/* We don't -- general case. */
X		do {
X			if (regtry(prog, s))
X				return(1);
X		} while (*s++ != '\0');
X
X	/* Failure. */
X	return(0);
X}
X
X/*
X - regtry - try match at specific point
X */
Xstatic int			/* 0 failure, 1 success */
Xregtry(prog, string)
Xregexp *prog;
Xchar *string;
X{
X	register int i;
X	register char **sp;
X	register char **ep;
X
X	reginput = string;
X	regstartp = prog->startp;
X	regendp = prog->endp;
X
X	sp = prog->startp;
X	ep = prog->endp;
X	for (i = NSUBEXP; i > 0; i--) {
X		*sp++ = NULL;
X		*ep++ = NULL;
X	}
X	if (regmatch(prog->program + 1)) {
X		prog->startp[0] = string;
X		prog->endp[0] = reginput;
X		return(1);
X	} else
X		return(0);
X}
X
X/*
X - regmatch - main matching routine
X *
X * Conceptually the strategy is simple:  check to see whether the current
X * node matches, call self recursively to see whether the rest matches,
X * and then act accordingly.  In practice we make some effort to avoid
X * recursion, in particular by going through "ordinary" nodes (that don't
X * need to know whether the rest of the match failed) by a loop instead of
X * by recursion.
X */
Xstatic int			/* 0 failure, 1 success */
Xregmatch(prog)
Xchar *prog;
X{
X	register char *scan;	/* Current node. */
X	char *next;		/* Next node. */
X	extern char *strchr();
X
X	scan = prog;
X#ifdef DEBUG
X	if (scan != NULL && regnarrate)
X		fprintf(stderr, "%s(\n", regprop(scan));
X#endif
X	while (scan != NULL) {
X#ifdef DEBUG
X		if (regnarrate)
X			fprintf(stderr, "%s...\n", regprop(scan));
X#endif
X		next = regnext(scan);
X
X		switch (OP(scan)) {
X		case BOL:
X			if (reginput != regbol)
X				return(0);
X			break;
X		case EOL:
X			if (*reginput != '\0')
X				return(0);
X			break;
X		case WORDA:
X			/* Must be looking at a letter, digit, or _ */
X			if ((!isalnum(*reginput)) && *reginput != '_')
X				return(0);
X			/* Prev must be BOL or nonword */
X			if (reginput > regbol &&
X			    (isalnum(reginput[-1]) || reginput[-1] == '_'))
X				return(0);
X			break;
X		case WORDZ:
X			/* Must be looking at non letter, digit, or _ */
X			if (isalnum(*reginput) || *reginput == '_')
X				return(0);
X			/* We don't care what the previous char was */
X			break;
X		case ANY:
X			if (*reginput == '\0')
X				return(0);
X			reginput++;
X			break;
X		case EXACTLY: {
X				register int len;
X				register char *opnd;
X
X				opnd = OPERAND(scan);
X				/* Inline the first character, for speed. */
X				if (CASE(*opnd) != CASE(*reginput))
X					return(0);
X				len = strlen(opnd);
X				if (len > 1 && STRNCMP(opnd, reginput, len) != 0)
X					return(0);
X				reginput += len;
X			}
X			break;
X		case ANYOF:
X 			if (*reginput == '\0' || STRCHR(OPERAND(scan), *reginput) == NULL)
X				return(0);
X			reginput++;
X			break;
X		case ANYBUT:
X 			if (*reginput == '\0' || STRCHR(OPERAND(scan), *reginput) != NULL)
X				return(0);
X			reginput++;
X			break;
X		case NOTHING:
X			break;
X		case BACK:
X			break;
X		case OPEN+1:
X		case OPEN+2:
X		case OPEN+3:
X		case OPEN+4:
X		case OPEN+5:
X		case OPEN+6:
X		case OPEN+7:
X		case OPEN+8:
X		case OPEN+9: {
X				register int no;
X				register char *save;
X
X				no = OP(scan) - OPEN;
X				save = reginput;
X
X				if (regmatch(next)) {
X					/*
X					 * Don't set startp if some later
X					 * invocation of the same parentheses
X					 * already has.
X					 */
X					if (regstartp[no] == NULL)
X						regstartp[no] = save;
X					return(1);
X				} else
X					return(0);
X			}
X			break;
X		case CLOSE+1:
X		case CLOSE+2:
X		case CLOSE+3:
X		case CLOSE+4:
X		case CLOSE+5:
X		case CLOSE+6:
X		case CLOSE+7:
X		case CLOSE+8:
X		case CLOSE+9: {
X				register int no;
X				register char *save;
X
X				no = OP(scan) - CLOSE;
X				save = reginput;
X
X				if (regmatch(next)) {
X					/*
X					 * Don't set endp if some later
X					 * invocation of the same parentheses
X					 * already has.
X					 */
X					if (regendp[no] == NULL)
X						regendp[no] = save;
X					return(1);
X				} else
X					return(0);
X			}
X			break;
X		case BRANCH: {
X				register char *save;
X
X				if (OP(next) != BRANCH)		/* No choice. */
X					next = OPERAND(scan);	/* Avoid recursion. */
X				else {
X					do {
X						save = reginput;
X						if (regmatch(OPERAND(scan)))
X							return(1);
X						reginput = save;
X						scan = regnext(scan);
X					} while (scan != NULL && OP(scan) == BRANCH);
X					return(0);
X					/* NOTREACHED */
X				}
X			}
X			break;
X		case STAR:
X		case PLUS: {
X				register char nextch;
X				register int no;
X				register char *save;
X				register int min;
X
X				/*
X				 * Lookahead to avoid useless match attempts
X				 * when we know what character comes next.
X				 */
X				nextch = '\0';
X				if (OP(next) == EXACTLY)
X					nextch = *OPERAND(next);
X				min = (OP(scan) == STAR) ? 0 : 1;
X				save = reginput;
X				no = regrepeat(OPERAND(scan));
X				while (no >= min) {
X					/* If it could work, try it. */
X					if (nextch == '\0' 
X					    || CASE(*reginput) == CASE(nextch))
X						if (regmatch(next))
X							return(1);
X					/* Couldn't or didn't -- back up. */
X					no--;
X					reginput = save + no;
X				}
X				return(0);
X			}
X			break;
X		case END:
X			return(1);	/* Success! */
X			break;
X		default:
X			regerror("memory corruption");
X			return(0);
X			break;
X		}
X
X		scan = next;
X	}
X
X	/*
X	 * We get here only if there's trouble -- normally "case END" is
X	 * the terminating point.
X	 */
X	regerror("corrupted pointers");
X	return(0);
X}
X
X/*
X - regrepeat - repeatedly match something simple, report how many
X */
Xstatic int
Xregrepeat(p)
Xchar *p;
X{
X	register int count = 0;
X	register char *scan;
X	register char *opnd;
X
X	scan = reginput;
X	opnd = OPERAND(p);
X	switch (OP(p)) {
X	case ANY:
X		count = strlen(scan);
X		scan += count;
X		break;
X	case EXACTLY:
X		while (CASE(*opnd) == CASE(*scan)) {
X			count++;
X			scan++;
X		}
X		break;
X	case ANYOF:
X		while (*scan != '\0' && STRCHR(opnd, *scan) != NULL) {
X			count++;
X			scan++;
X		}
X		break;
X	case ANYBUT:
X		while (*scan != '\0' && STRCHR(opnd, *scan) == NULL) {
X			count++;
X			scan++;
X		}
X		break;
X	default:		/* Oh dear.  Called inappropriately. */
X		regerror("internal foulup");
X		count = 0;	/* Best compromise. */
X		break;
X	}
X	reginput = scan;
X
X	return(count);
X}
X
X/*
X - regnext - dig the "next" pointer out of a node
X */
Xstatic char *
Xregnext(p)
Xregister char *p;
X{
X	register int offset;
X
X	if (p == &regdummy)
X		return(NULL);
X
X	offset = NEXT(p);
X	if (offset == 0)
X		return(NULL);
X
X	if (OP(p) == BACK)
X		return(p-offset);
X	else
X		return(p+offset);
X}
X
X#ifdef DEBUG
X
XSTATIC char *regprop();
X
X/*
X - regdump - dump a regexp onto stdout in vaguely comprehensible form
X */
Xvoid
Xregdump(r)
Xregexp *r;
X{
X	register char *s;
X	register char op = EXACTLY;	/* Arbitrary non-END op. */
X	register char *next;
X	extern char *strchr();
X
X
X	s = r->program + 1;
X	while (op != END) {	/* While that wasn't END last time... */
X		op = OP(s);
X		printf("%2d%s", s-r->program, regprop(s));	/* Where, what. */
X		next = regnext(s);
X		if (next == NULL)		/* Next ptr. */
X			printf("(0)");
X		else 
X			printf("(%d)", (s-r->program)+(next-s));
X		s += 3;
X		if (op == ANYOF || op == ANYBUT || op == EXACTLY) {
X			/* Literal string, where present. */
X			while (*s != '\0') {
X				putchar(*s);
X				s++;
X			}
X			s++;
X		}
X		putchar('\n');
X	}
X
X	/* Header fields of interest. */
X	if (r->regstart != '\0')
X		printf("start `%c' ", r->regstart);
X	if (r->reganch)
X		printf("anchored ");
X	if (r->regmust != NULL)
X		printf("must have \"%s\"", r->regmust);
X	printf("\n");
X}
X
X/*
X - regprop - printable representation of opcode
X */
Xstatic char *
Xregprop(op)
Xchar *op;
X{
X	register char *p;
X	static char buf[50];
X
X	(void) strcpy(buf, ":");
X
X	switch (OP(op)) {
X	case BOL:
X		p = "BOL";
X		break;
X	case EOL:
X		p = "EOL";
X		break;
X	case ANY:
X		p = "ANY";
X		break;
X	case ANYOF:
X		p = "ANYOF";
X		break;
X	case ANYBUT:
X		p = "ANYBUT";
X		break;
X	case BRANCH:
X		p = "BRANCH";
X		break;
X	case EXACTLY:
X		p = "EXACTLY";
X		break;
X	case NOTHING:
X		p = "NOTHING";
X		break;
X	case BACK:
X		p = "BACK";
X		break;
X	case END:
X		p = "END";
X		break;
X	case OPEN+1:
X	case OPEN+2:
X	case OPEN+3:
X	case OPEN+4:
X	case OPEN+5:
X	case OPEN+6:
X	case OPEN+7:
X	case OPEN+8:
X	case OPEN+9:
X		sprintf(buf+strlen(buf), "OPEN%d", OP(op)-OPEN);
X		p = NULL;
X		break;
X	case CLOSE+1:
X	case CLOSE+2:
X	case CLOSE+3:
X	case CLOSE+4:
X	case CLOSE+5:
X	case CLOSE+6:
X	case CLOSE+7:
X	case CLOSE+8:
X	case CLOSE+9:
X		sprintf(buf+strlen(buf), "CLOSE%d", OP(op)-CLOSE);
X		p = NULL;
X		break;
X	case STAR:
X		p = "STAR";
X		break;
X	case PLUS:
X		p = "PLUS";
X		break;
X	case WORDA:
X		p = "WORDA";
X		break;
X	case WORDZ:
X		p = "WORDZ";
X		break;
X	default:
X		regerror("corrupted opcode");
X		break;
X	}
X	if (p != NULL)
X		(void) strcat(buf, p);
X	return(buf);
X}
X#endif
X
X/*
X * The following is provided for those people who do not have strcspn() in
X * their C libraries.  They should get off their butts and do something
X * about it; at least one public-domain implementation of those (highly
X * useful) string routines has been published on Usenet.
X */
X#ifdef STRCSPN
X/*
X * strcspn - find length of initial segment of s1 consisting entirely
X * of characters not from s2
X */
X
Xstatic int
Xstrcspn(s1, s2)
Xchar *s1;
Xchar *s2;
X{
X	register char *scan1;
X	register char *scan2;
X	register int count;
X
X	count = 0;
X	for (scan1 = s1; *scan1 != '\0'; scan1++) {
X		for (scan2 = s2; *scan2 != '\0';)	/* ++ moved down. */
X			if (CASE(*scan1) == CASE(*scan2++))
X				return(count);
X		count++;
X	}
X	return(count);
X}
X#endif
END_OF_FILE
if test 31972 -ne `wc -c <'regexp.c'`; then
    echo shar: \"'regexp.c'\" unpacked with wrong size!
fi
# end of 'regexp.c'
fi
if test -f 'regexp.c.orig' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regexp.c.orig'\"
else
echo shar: Extracting \"'regexp.c.orig'\" \(31244 characters\)
sed "s/^X//" >'regexp.c.orig' <<'END_OF_FILE'
X/*
X * regcomp and regexec -- regsub and regerror are elsewhere
X *
X *	Copyright (c) 1986 by University of Toronto.
X *	Written by Henry Spencer.  Not derived from licensed software.
X *
X *	Permission is granted to anyone to use this software for any
X *	purpose on any computer system, and to redistribute it freely,
X *	subject to the following restrictions:
X *
X *	1. The author is not responsible for the consequences of use of
X *		this software, no matter how awful, even if they arise
X *		from defects in it.
X *
X *	2. The origin of this software must not be misrepresented, either
X *		by explicit claim or by omission.
X *
X *	3. Altered versions must be plainly marked as such, and must not
X *		be misrepresented as being the original software.
X *** THIS IS AN ALTERED VERSION.  It was altered by John Gilmore,
X *** hoptoad!gnu, on 27 Dec 1986, to add \n as an alternative to |
X *** to assist in implementing egrep.
X *** THIS IS AN ALTERED VERSION.  It was altered by John Gilmore,
X *** hoptoad!gnu, on 27 Dec 1986, to add \< and \> for word-matching
X *** as in BSD grep and ex.
X *** THIS IS AN ALTERED VERSION.  It was altered by John Gilmore,
X *** hoptoad!gnu, on 28 Dec 1986, to optimize characters quoted with \.
X *** THIS IS AN ALTERED VERSION.  It was altered by James A. Woods,
X *** ames!jaw, on 19 June 1987, to quash a regcomp() redundancy.
X *
X * Beware that some of this code is subtly aware of the way operator
X * precedence is structured in regular expressions.  Serious changes in
X * regular-expression syntax might require a total rethink.
X */
X#include <regexp.h>
X#include <stdio.h>
X#include <ctype.h>
X#include <stdlib.h>
X#include <string.h>
X#include "regmagic.h"
X
X/*
X * The "internal use only" fields in regexp.h are present to pass info from
X * compile to execute that permits the execute phase to run lots faster on
X * simple cases.  They are:
X *
X * regstart	char that must begin a match; '\0' if none obvious
X * reganch	is the match anchored (at beginning-of-line only)?
X * regmust	string (pointer into program) that match must include, or NULL
X * regmlen	length of regmust string
X *
X * Regstart and reganch permit very fast decisions on suitable starting points
X * for a match, cutting down the work a lot.  Regmust permits fast rejection
X * of lines that cannot possibly match.  The regmust tests are costly enough
X * that regcomp() supplies a regmust only if the r.e. contains something
X * potentially expensive (at present, the only such thing detected is * or +
X * at the start of the r.e., which can involve a lot of backup).  Regmlen is
X * supplied because the test in regexec() needs it and regcomp() is computing
X * it anyway.
X */
X
X/*
X * Structure for regexp "program".  This is essentially a linear encoding
X * of a nondeterministic finite-state machine (aka syntax charts or
X * "railroad normal form" in parsing technology).  Each node is an opcode
X * plus a "next" pointer, possibly plus an operand.  "Next" pointers of
X * all nodes except BRANCH implement concatenation; a "next" pointer with
X * a BRANCH on both ends of it is connecting two alternatives.  (Here we
X * have one of the subtle syntax dependencies:  an individual BRANCH (as
X * opposed to a collection of them) is never concatenated with anything
X * because of operator precedence.)  The operand of some types of node is
X * a literal string; for others, it is a node leading into a sub-FSM.  In
X * particular, the operand of a BRANCH node is the first node of the branch.
X * (NB this is *not* a tree structure:  the tail of the branch connects
X * to the thing following the set of BRANCHes.)  The opcodes are:
X */
X
X/* definition	number	opnd?	meaning */
X#define	END	0	/* no	End of program. */
X#define	BOL	1	/* no	Match "" at beginning of line. */
X#define	EOL	2	/* no	Match "" at end of line. */
X#define	ANY	3	/* no	Match any one character. */
X#define	ANYOF	4	/* str	Match any character in this string. */
X#define	ANYBUT	5	/* str	Match any character not in this string. */
X#define	BRANCH	6	/* node	Match this alternative, or the next... */
X#define	BACK	7	/* no	Match "", "next" ptr points backward. */
X#define	EXACTLY	8	/* str	Match this string. */
X#define	NOTHING	9	/* no	Match empty string. */
X#define	STAR	10	/* node	Match this (simple) thing 0 or more times. */
X#define	PLUS	11	/* node	Match this (simple) thing 1 or more times. */
X#define	WORDA	12	/* no	Match "" at wordchar, where prev is nonword */
X#define	WORDZ	13	/* no	Match "" at nonwordchar, where prev is word */
X#define	OPEN	20	/* no	Mark this point in input as start of #n. */
X			/*	OPEN+1 is number 1, etc. */
X#define	CLOSE	30	/* no	Analogous to OPEN. */
X
X/*
X * Opcode notes:
X *
X * BRANCH	The set of branches constituting a single choice are hooked
X *		together with their "next" pointers, since precedence prevents
X *		anything being concatenated to any individual branch.  The
X *		"next" pointer of the last BRANCH in a choice points to the
X *		thing following the whole choice.  This is also where the
X *		final "next" pointer of each individual branch points; each
X *		branch starts with the operand node of a BRANCH node.
X *
X * BACK		Normal "next" pointers all implicitly point forward; BACK
X *		exists to make loop structures possible.
X *
X * STAR,PLUS	'?', and complex '*' and '+', are implemented as circular
X *		BRANCH structures using BACK.  Simple cases (one character
X *		per match) are implemented with STAR and PLUS for speed
X *		and to minimize recursive plunges.
X *
X * OPEN,CLOSE	...are numbered at compile time.
X */
X
X/*
X * A node is one char of opcode followed by two chars of "next" pointer.
X * "Next" pointers are stored as two 8-bit pieces, high order first.  The
X * value is a positive offset from the opcode of the node containing it.
X * An operand, if any, simply follows the node.  (Note that much of the
X * code generation knows about this implicit relationship.)
X *
X * Using two bytes for the "next" pointer is vast overkill for most things,
X * but allows patterns to get big without disasters.
X */
X#define	OP(p)	(*(p))
X#define	NEXT(p)	(((*((p)+1)&0377)<<8) + (*((p)+2)&0377))
X#define	OPERAND(p)	((p) + 3)
X
X/*
X * See regmagic.h for one further detail of program structure.
X */
X
X
X/*
X * Utility definitions.
X */
X#ifndef CHARBITS
X#define	UCHARAT(p)	((int)*(unsigned char *)(p))
X#else
X#define	UCHARAT(p)	((int)*(p)&CHARBITS)
X#endif
X
X#define	FAIL(m)	{ regerror(m); return(NULL); }
X#define	ISMULT(c)	((c) == '*' || (c) == '+' || (c) == '?')
X
X/*
X * Flags to be passed up and down.
X */
X#define	HASWIDTH	01	/* Known never to match null string. */
X#define	SIMPLE		02	/* Simple enough to be STAR/PLUS operand. */
X#define	SPSTART		04	/* Starts with * or +. */
X#define	WORST		0	/* Worst case. */
X
X/*
X * Global work variables for regcomp().
X */
Xstatic char *regparse;		/* Input-scan pointer. */
Xstatic int regnpar;		/* () count. */
Xstatic char regdummy;
Xstatic char *regcode;		/* Code-emit pointer; &regdummy = don't. */
Xstatic long regsize;		/* Code size. */
X
X/*
X * Forward declarations for regcomp()'s friends.
X */
X#ifndef STATIC
X#define	STATIC	static
X#endif
XSTATIC char *reg();
XSTATIC char *regbranch();
XSTATIC char *regpiece();
XSTATIC char *regatom();
XSTATIC char *regnode();
XSTATIC char *regnext();
XSTATIC void regc();
XSTATIC void reginsert();
XSTATIC void regtail();
XSTATIC void regoptail();
X#ifdef STRCSPN
XSTATIC int strcspn();
X#endif
X
X/*
X - regcomp - compile a regular expression into internal code
X *
X * We can't allocate space until we know how big the compiled form will be,
X * but we can't compile it (and thus know how big it is) until we've got a
X * place to put the code.  So we cheat:  we compile it twice, once with code
X * generation turned off and size counting turned on, and once "for real".
X * This also means that we don't allocate space until we are sure that the
X * thing really will compile successfully, and we never have to move the
X * code and thus invalidate pointers into it.  (Note that it has to be in
X * one piece because free() must be able to free it all.)
X *
X * Beware that the optimization-preparation code in here knows about some
X * of the structure of the compiled regexp.
X */
Xregexp *
Xregcomp(exp)
Xconst char *exp;
X{
X	register regexp *r;
X	register char *scan;
X	register char *longest;
X	register int len;
X	int flags;
X
X	if (exp == NULL)
X		FAIL("NULL argument");
X
X	/* First pass: determine size, legality. */
X#ifdef notdef
X	if (exp[0] == '.' && exp[1] == '*') exp += 2;  /* aid grep */
X#endif
X	regparse = (char *)exp;
X	regnpar = 1;
X	regsize = 0L;
X	regcode = &regdummy;
X	regc(MAGIC);
X	if (reg(0, &flags) == NULL)
X		return(NULL);
X
X	/* Small enough for pointer-storage convention? */
X	if (regsize >= 32767L)		/* Probably could be 65535L. */
X		FAIL("regexp too big");
X
X	/* Allocate space. */
X	r = (regexp *)malloc(sizeof(regexp) + (unsigned)regsize);
X	if (r == NULL)
X		FAIL("out of space");
X
X	/* Second pass: emit code. */
X	regparse = (char *)exp;
X	regnpar = 1;
X	regcode = r->program;
X	regc(MAGIC);
X	if (reg(0, &flags) == NULL)
X		return(NULL);
X
X	/* Dig out information for optimizations. */
X	r->regstart = '\0';	/* Worst-case defaults. */
X	r->reganch = 0;
X	r->regmust = NULL;
X	r->regmlen = 0;
X	scan = r->program+1;			/* First BRANCH. */
X	if (OP(regnext(scan)) == END) {		/* Only one top-level choice. */
X		scan = OPERAND(scan);
X
X		/* Starting-point info. */
X		if (OP(scan) == EXACTLY)
X			r->regstart = *OPERAND(scan);
X		else if (OP(scan) == BOL)
X			r->reganch++;
X
X		/*
X		 * If there's something expensive in the r.e., find the
X		 * longest literal string that must appear and make it the
X		 * regmust.  Resolve ties in favor of later strings, since
X		 * the regstart check works with the beginning of the r.e.
X		 * and avoiding duplication strengthens checking.  Not a
X		 * strong reason, but sufficient in the absence of others.
X		 */
X		if (flags&SPSTART) {
X			longest = NULL;
X			len = 0;
X			for (; scan != NULL; scan = regnext(scan))
X				if (OP(scan) == EXACTLY && strlen(OPERAND(scan)) >= len) {
X					longest = OPERAND(scan);
X					len = strlen(OPERAND(scan));
X				}
X			r->regmust = longest;
X			r->regmlen = len;
X		}
X	}
X
X	return(r);
X}
X
X/*
X - reg - regular expression, i.e. main body or parenthesized thing
X *
X * Caller must absorb opening parenthesis.
X *
X * Combining parenthesis handling with the base level of regular expression
X * is a trifle forced, but the need to tie the tails of the branches to what
X * follows makes it hard to avoid.
X */
Xstatic char *
Xreg(paren, flagp)
Xint paren;			/* Parenthesized? */
Xint *flagp;
X{
X	register char *ret;
X	register char *br;
X	register char *ender;
X	register int parno;
X	int flags;
X
X	*flagp = HASWIDTH;	/* Tentatively. */
X
X	/* Make an OPEN node, if parenthesized. */
X	if (paren) {
X		if (regnpar >= NSUBEXP)
X			FAIL("too many ()");
X		parno = regnpar;
X		regnpar++;
X		ret = regnode(OPEN+parno);
X	} else
X		ret = NULL;
X
X	/* Pick up the branches, linking them together. */
X	br = regbranch(&flags);
X	if (br == NULL)
X		return(NULL);
X	if (ret != NULL)
X		regtail(ret, br);	/* OPEN -> first. */
X	else
X		ret = br;
X	if (!(flags&HASWIDTH))
X		*flagp &= ~HASWIDTH;
X	*flagp |= flags&SPSTART;
X	while (*regparse == '|' || *regparse == '\n') {
X		regparse++;
X		br = regbranch(&flags);
X		if (br == NULL)
X			return(NULL);
X		regtail(ret, br);	/* BRANCH -> BRANCH. */
X		if (!(flags&HASWIDTH))
X			*flagp &= ~HASWIDTH;
X		*flagp |= flags&SPSTART;
X	}
X
X	/* Make a closing node, and hook it on the end. */
X	ender = regnode((paren) ? CLOSE+parno : END);	
X	regtail(ret, ender);
X
X	/* Hook the tails of the branches to the closing node. */
X	for (br = ret; br != NULL; br = regnext(br))
X		regoptail(br, ender);
X
X	/* Check for proper termination. */
X	if (paren && *regparse++ != ')') {
X		FAIL("unmatched ()");
X	} else if (!paren && *regparse != '\0') {
X		if (*regparse == ')') {
X			FAIL("unmatched ()");
X		} else
X			FAIL("junk on end");	/* "Can't happen". */
X		/* NOTREACHED */
X	}
X
X	return(ret);
X}
X
X/*
X - regbranch - one alternative of an | operator
X *
X * Implements the concatenation operator.
X */
Xstatic char *
Xregbranch(flagp)
Xint *flagp;
X{
X	register char *ret;
X	register char *chain;
X	register char *latest;
X	int flags;
X
X	*flagp = WORST;		/* Tentatively. */
X
X	ret = regnode(BRANCH);
X	chain = NULL;
X	while (*regparse != '\0' && *regparse != ')' &&
X	       *regparse != '\n' && *regparse != '|') {
X		latest = regpiece(&flags);
X		if (latest == NULL)
X			return(NULL);
X		*flagp |= flags&HASWIDTH;
X		if (chain == NULL)	/* First piece. */
X			*flagp |= flags&SPSTART;
X		else
X			regtail(chain, latest);
X		chain = latest;
X	}
X	if (chain == NULL)	/* Loop ran zero times. */
X		(void) regnode(NOTHING);
X
X	return(ret);
X}
X
X/*
X - regpiece - something followed by possible [*+?]
X *
X * Note that the branching code sequences used for ? and the general cases
X * of * and + are somewhat optimized:  they use the same NOTHING node as
X * both the endmarker for their branch list and the body of the last branch.
X * It might seem that this node could be dispensed with entirely, but the
X * endmarker role is not redundant.
X */
Xstatic char *
Xregpiece(flagp)
Xint *flagp;
X{
X	register char *ret;
X	register char op;
X	register char *next;
X	int flags;
X
X	ret = regatom(&flags);
X	if (ret == NULL)
X		return(NULL);
X
X	op = *regparse;
X	if (!ISMULT(op)) {
X		*flagp = flags;
X		return(ret);
X	}
X
X	if (!(flags&HASWIDTH) && op != '?')
X		FAIL("*+ operand could be empty");
X	*flagp = (op != '+') ? (WORST|SPSTART) : (WORST|HASWIDTH);
X
X	if (op == '*' && (flags&SIMPLE))
X		reginsert(STAR, ret);
X	else if (op == '*') {
X		/* Emit x* as (x&|), where & means "self". */
X		reginsert(BRANCH, ret);			/* Either x */
X		regoptail(ret, regnode(BACK));		/* and loop */
X		regoptail(ret, ret);			/* back */
X		regtail(ret, regnode(BRANCH));		/* or */
X		regtail(ret, regnode(NOTHING));		/* null. */
X	} else if (op == '+' && (flags&SIMPLE))
X		reginsert(PLUS, ret);
X	else if (op == '+') {
X		/* Emit x+ as x(&|), where & means "self". */
X		next = regnode(BRANCH);			/* Either */
X		regtail(ret, next);
X		regtail(regnode(BACK), ret);		/* loop back */
X		regtail(next, regnode(BRANCH));		/* or */
X		regtail(ret, regnode(NOTHING));		/* null. */
X	} else if (op == '?') {
X		/* Emit x? as (x|) */
X		reginsert(BRANCH, ret);			/* Either x */
X		regtail(ret, regnode(BRANCH));		/* or */
X		next = regnode(NOTHING);		/* null. */
X		regtail(ret, next);
X		regoptail(ret, next);
X	}
X	regparse++;
X	if (ISMULT(*regparse))
X		FAIL("nested *?+");
X
X	return(ret);
X}
X
X/*
X - regatom - the lowest level
X *
X * Optimization:  gobbles an entire sequence of ordinary characters so that
X * it can turn them into a single node, which is smaller to store and
X * faster to run.  Backslashed characters are exceptions, each becoming a
X * separate node; the code is simpler that way and it's not worth fixing.
X */
Xstatic char *
Xregatom(flagp)
Xint *flagp;
X{
X	register char *ret;
X	int flags;
X
X	*flagp = WORST;		/* Tentatively. */
X
X	switch (*regparse++) {
X	/* FIXME: these chars only have meaning at beg/end of pat? */
X	case '^':
X		ret = regnode(BOL);
X		break;
X	case '$':
X		ret = regnode(EOL);
X		break;
X	case '.':
X		ret = regnode(ANY);
X		*flagp |= HASWIDTH|SIMPLE;
X		break;
X	case '[': {
X			register int class;
X			register int classend;
X
X			if (*regparse == '^') {	/* Complement of range. */
X				ret = regnode(ANYBUT);
X				regparse++;
X			} else
X				ret = regnode(ANYOF);
X			if (*regparse == ']' || *regparse == '-')
X				regc(*regparse++);
X			while (*regparse != '\0' && *regparse != ']') {
X				if (*regparse == '-') {
X					regparse++;
X					if (*regparse == ']' || *regparse == '\0')
X						regc('-');
X					else {
X						class = UCHARAT(regparse-2)+1;
X						classend = UCHARAT(regparse);
X						if (class > classend+1)
X							FAIL("invalid [] range");
X						for (; class <= classend; class++)
X							regc(class);
X						regparse++;
X					}
X				} else
X					regc(*regparse++);
X			}
X			regc('\0');
X			if (*regparse != ']')
X				FAIL("unmatched []");
X			regparse++;
X			*flagp |= HASWIDTH|SIMPLE;
X		}
X		break;
X	case '(':
X		ret = reg(1, &flags);
X		if (ret == NULL)
X			return(NULL);
X		*flagp |= flags&(HASWIDTH|SPSTART);
X		break;
X	case '\0':
X	case '|':
X	case '\n':
X	case ')':
X		FAIL("internal urp");	/* Supposed to be caught earlier. */
X		break;
X	case '?':
X	case '+':
X	case '*':
X		FAIL("?+* follows nothing");
X		break;
X	case '\\':
X		switch (*regparse++) {
X		case '\0':
X			FAIL("trailing \\");
X			break;
X		case '<':
X			ret = regnode(WORDA);
X			break;
X		case '>':
X			ret = regnode(WORDZ);
X			break;
X		/* FIXME: Someday handle \1, \2, ... */
X		default:
X			/* Handle general quoted chars in exact-match routine */
X			goto de_fault;
X		}
X		break;
X	de_fault:
X	default:
X		/*
X		 * Encode a string of characters to be matched exactly.
X		 *
X		 * This is a bit tricky due to quoted chars and due to
X		 * '*', '+', and '?' taking the SINGLE char previous
X		 * as their operand.
X		 *
X		 * On entry, the char at regparse[-1] is going to go
X		 * into the string, no matter what it is.  (It could be
X		 * following a \ if we are entered from the '\' case.)
X		 * 
X		 * Basic idea is to pick up a good char in  ch  and
X		 * examine the next char.  If it's *+? then we twiddle.
X		 * If it's \ then we frozzle.  If it's other magic char
X		 * we push  ch  and terminate the string.  If none of the
X		 * above, we push  ch  on the string and go around again.
X		 *
X		 *  regprev  is used to remember where "the current char"
X		 * starts in the string, if due to a *+? we need to back
X		 * up and put the current char in a separate, 1-char, string.
X		 * When  regprev  is NULL,  ch  is the only char in the
X		 * string; this is used in *+? handling, and in setting
X		 * flags |= SIMPLE at the end.
X		 */
X		{
X			char *regprev;
X			register char ch;
X
X			regparse--;			/* Look at cur char */
X			ret = regnode(EXACTLY);
X			for ( regprev = 0 ; ; ) {
X				ch = *regparse++;	/* Get current char */
X				switch (*regparse) {	/* look at next one */
X
X				default:
X					regc(ch);	/* Add cur to string */
X					break;
X
X				case '.': case '[': case '(':
X				case ')': case '|': case '\n':
X				case '$': case '^':
X				case '\0':
X				/* FIXME, $ and ^ should not always be magic */
X				magic:
X					regc(ch);	/* dump cur char */
X					goto done;	/* and we are done */
X
X				case '?': case '+': case '*':
X					if (!regprev) 	/* If just ch in str, */
X						goto magic;	/* use it */
X					/* End mult-char string one early */
X					regparse = regprev; /* Back up parse */
X					goto done;
X
X				case '\\':
X					regc(ch);	/* Cur char OK */
X					switch (regparse[1]){ /* Look after \ */
X					case '\0':
X					case '<':
X					case '>':
X					/* FIXME: Someday handle \1, \2, ... */
X						goto done; /* Not quoted */
X					default:
X						/* Backup point is \, scan							 * point is after it. */
X						regprev = regparse;
X						regparse++; 
X						continue;	/* NOT break; */
X					}
X				}
X				regprev = regparse;	/* Set backup point */
X			}
X		done:
X			regc('\0');
X			*flagp |= HASWIDTH;
X			if (!regprev)		/* One char? */
X				*flagp |= SIMPLE;
X		}
X		break;
X	}
X
X	return(ret);
X}
X
X/*
X - regnode - emit a node
X */
Xstatic char *			/* Location. */
Xregnode(op)
Xchar op;
X{
X	register char *ret;
X	register char *ptr;
X
X	ret = regcode;
X	if (ret == &regdummy) {
X		regsize += 3;
X		return(ret);
X	}
X
X	ptr = ret;
X	*ptr++ = op;
X	*ptr++ = '\0';		/* Null "next" pointer. */
X	*ptr++ = '\0';
X	regcode = ptr;
X
X	return(ret);
X}
X
X/*
X - regc - emit (if appropriate) a byte of code
X */
Xstatic void
Xregc(b)
Xchar b;
X{
X	if (regcode != &regdummy)
X		*regcode++ = b;
X	else
X		regsize++;
X}
X
X/*
X - reginsert - insert an operator in front of already-emitted operand
X *
X * Means relocating the operand.
X */
Xstatic void
Xreginsert(op, opnd)
Xchar op;
Xchar *opnd;
X{
X	register char *src;
X	register char *dst;
X	register char *place;
X
X	if (regcode == &regdummy) {
X		regsize += 3;
X		return;
X	}
X
X	src = regcode;
X	regcode += 3;
X	dst = regcode;
X	while (src > opnd)
X		*--dst = *--src;
X
X	place = opnd;		/* Op node, where operand used to be. */
X	*place++ = op;
X	*place++ = '\0';
X	*place++ = '\0';
X}
X
X/*
X - regtail - set the next-pointer at the end of a node chain
X */
Xstatic void
Xregtail(p, val)
Xchar *p;
Xchar *val;
X{
X	register char *scan;
X	register char *temp;
X	register int offset;
X
X	if (p == &regdummy)
X		return;
X
X	/* Find last node. */
X	scan = p;
X	for (;;) {
X		temp = regnext(scan);
X		if (temp == NULL)
X			break;
X		scan = temp;
X	}
X
X	if (OP(scan) == BACK)
X		offset = scan - val;
X	else
X		offset = val - scan;
X	*(scan+1) = (offset>>8)&0377;
X	*(scan+2) = offset&0377;
X}
X
X/*
X - regoptail - regtail on operand of first argument; nop if operandless
X */
Xstatic void
Xregoptail(p, val)
Xchar *p;
Xchar *val;
X{
X	/* "Operandless" and "op != BRANCH" are synonymous in practice. */
X	if (p == NULL || p == &regdummy || OP(p) != BRANCH)
X		return;
X	regtail(OPERAND(p), val);
X}
X
X/*
X * regexec and friends
X */
X
X/*
X * Global work variables for regexec().
X */
Xstatic char *reginput;		/* String-input pointer. */
Xstatic char *regbol;		/* Beginning of input, for ^ check. */
Xstatic char **regstartp;	/* Pointer to startp array. */
Xstatic char **regendp;		/* Ditto for endp. */
X
X/*
X * Forwards.
X */
XSTATIC int regtry();
XSTATIC int regmatch();
XSTATIC int regrepeat();
X
X#ifdef DEBUG
Xint regnarrate = 0;
Xvoid regdump();
XSTATIC char *regprop();
X#endif
X
X/*
X - regexec - match a regexp against a string
X */
Xint
Xregexec(prog, string)
Xregister const regexp *prog;
Xregister const char *string;
X{
X	register char *s;
X	extern char *strchr();
X
X	/* Be paranoid... */
X	if (prog == NULL || string == NULL) {
X		regerror("NULL parameter");
X		return(0);
X	}
X
X	/* Check validity of program. */
X	if (UCHARAT(prog->program) != MAGIC) {
X		regerror("corrupted program");
X		return(0);
X	}
X
X	/* If there is a "must appear" string, look for it. */
X	if (prog->regmust != NULL) {
X		s = (char *)string;
X		while ((s = strchr(s, prog->regmust[0])) != NULL) {
X			if (strncmp(s, prog->regmust, prog->regmlen) == 0)
X				break;	/* Found it. */
X			s++;
X		}
X		if (s == NULL)	/* Not present. */
X			return(0);
X	}
X
X	/* Mark beginning of line for ^ . */
X	regbol = (char *)string;
X
X	/* Simplest case:  anchored match need be tried only once. */
X	if (prog->reganch)
X		return(regtry(prog, string));
X
X	/* Messy cases:  unanchored match. */
X	s = (char *)string;
X	if (prog->regstart != '\0')
X		/* We know what char it must start with. */
X		while ((s = strchr(s, prog->regstart)) != NULL) {
X			if (regtry(prog, s))
X				return(1);
X			s++;
X		}
X	else
X		/* We don't -- general case. */
X		do {
X			if (regtry(prog, s))
X				return(1);
X		} while (*s++ != '\0');
X
X	/* Failure. */
X	return(0);
X}
X
X/*
X - regtry - try match at specific point
X */
Xstatic int			/* 0 failure, 1 success */
Xregtry(prog, string)
Xregexp *prog;
Xchar *string;
X{
X	register int i;
X	register char **sp;
X	register char **ep;
X
X	reginput = string;
X	regstartp = prog->startp;
X	regendp = prog->endp;
X
X	sp = prog->startp;
X	ep = prog->endp;
X	for (i = NSUBEXP; i > 0; i--) {
X		*sp++ = NULL;
X		*ep++ = NULL;
X	}
X	if (regmatch(prog->program + 1)) {
X		prog->startp[0] = string;
X		prog->endp[0] = reginput;
X		return(1);
X	} else
X		return(0);
X}
X
X/*
X - regmatch - main matching routine
X *
X * Conceptually the strategy is simple:  check to see whether the current
X * node matches, call self recursively to see whether the rest matches,
X * and then act accordingly.  In practice we make some effort to avoid
X * recursion, in particular by going through "ordinary" nodes (that don't
X * need to know whether the rest of the match failed) by a loop instead of
X * by recursion.
X */
Xstatic int			/* 0 failure, 1 success */
Xregmatch(prog)
Xchar *prog;
X{
X	register char *scan;	/* Current node. */
X	char *next;		/* Next node. */
X	extern char *strchr();
X
X	scan = prog;
X#ifdef DEBUG
X	if (scan != NULL && regnarrate)
X		fprintf(stderr, "%s(\n", regprop(scan));
X#endif
X	while (scan != NULL) {
X#ifdef DEBUG
X		if (regnarrate)
X			fprintf(stderr, "%s...\n", regprop(scan));
X#endif
X		next = regnext(scan);
X
X		switch (OP(scan)) {
X		case BOL:
X			if (reginput != regbol)
X				return(0);
X			break;
X		case EOL:
X			if (*reginput != '\0')
X				return(0);
X			break;
X		case WORDA:
X			/* Must be looking at a letter, digit, or _ */
X			if ((!isalnum(*reginput)) && *reginput != '_')
X				return(0);
X			/* Prev must be BOL or nonword */
X			if (reginput > regbol &&
X			    (isalnum(reginput[-1]) || reginput[-1] == '_'))
X				return(0);
X			break;
X		case WORDZ:
X			/* Must be looking at non letter, digit, or _ */
X			if (isalnum(*reginput) || *reginput == '_')
X				return(0);
X			/* We don't care what the previous char was */
X			break;
X		case ANY:
X			if (*reginput == '\0')
X				return(0);
X			reginput++;
X			break;
X		case EXACTLY: {
X				register int len;
X				register char *opnd;
X
X				opnd = OPERAND(scan);
X				/* Inline the first character, for speed. */
X				if (*opnd != *reginput)
X					return(0);
X				len = strlen(opnd);
X				if (len > 1 && strncmp(opnd, reginput, len) != 0)
X					return(0);
X				reginput += len;
X			}
X			break;
X		case ANYOF:
X 			if (*reginput == '\0' || strchr(OPERAND(scan), *reginput) == NULL)
X				return(0);
X			reginput++;
X			break;
X		case ANYBUT:
X 			if (*reginput == '\0' || strchr(OPERAND(scan), *reginput) != NULL)
X				return(0);
X			reginput++;
X			break;
X		case NOTHING:
X			break;
X		case BACK:
X			break;
X		case OPEN+1:
X		case OPEN+2:
X		case OPEN+3:
X		case OPEN+4:
X		case OPEN+5:
X		case OPEN+6:
X		case OPEN+7:
X		case OPEN+8:
X		case OPEN+9: {
X				register int no;
X				register char *save;
X
X				no = OP(scan) - OPEN;
X				save = reginput;
X
X				if (regmatch(next)) {
X					/*
X					 * Don't set startp if some later
X					 * invocation of the same parentheses
X					 * already has.
X					 */
X					if (regstartp[no] == NULL)
X						regstartp[no] = save;
X					return(1);
X				} else
X					return(0);
X			}
X			break;
X		case CLOSE+1:
X		case CLOSE+2:
X		case CLOSE+3:
X		case CLOSE+4:
X		case CLOSE+5:
X		case CLOSE+6:
X		case CLOSE+7:
X		case CLOSE+8:
X		case CLOSE+9: {
X				register int no;
X				register char *save;
X
X				no = OP(scan) - CLOSE;
X				save = reginput;
X
X				if (regmatch(next)) {
X					/*
X					 * Don't set endp if some later
X					 * invocation of the same parentheses
X					 * already has.
X					 */
X					if (regendp[no] == NULL)
X						regendp[no] = save;
X					return(1);
X				} else
X					return(0);
X			}
X			break;
X		case BRANCH: {
X				register char *save;
X
X				if (OP(next) != BRANCH)		/* No choice. */
X					next = OPERAND(scan);	/* Avoid recursion. */
X				else {
X					do {
X						save = reginput;
X						if (regmatch(OPERAND(scan)))
X							return(1);
X						reginput = save;
X						scan = regnext(scan);
X					} while (scan != NULL && OP(scan) == BRANCH);
X					return(0);
X					/* NOTREACHED */
X				}
X			}
X			break;
X		case STAR:
X		case PLUS: {
X				register char nextch;
X				register int no;
X				register char *save;
X				register int min;
X
X				/*
X				 * Lookahead to avoid useless match attempts
X				 * when we know what character comes next.
X				 */
X				nextch = '\0';
X				if (OP(next) == EXACTLY)
X					nextch = *OPERAND(next);
X				min = (OP(scan) == STAR) ? 0 : 1;
X				save = reginput;
X				no = regrepeat(OPERAND(scan));
X				while (no >= min) {
X					/* If it could work, try it. */
X					if (nextch == '\0' || *reginput == nextch)
X						if (regmatch(next))
X							return(1);
X					/* Couldn't or didn't -- back up. */
X					no--;
X					reginput = save + no;
X				}
X				return(0);
X			}
X			break;
X		case END:
X			return(1);	/* Success! */
X			break;
X		default:
X			regerror("memory corruption");
X			return(0);
X			break;
X		}
X
X		scan = next;
X	}
X
X	/*
X	 * We get here only if there's trouble -- normally "case END" is
X	 * the terminating point.
X	 */
X	regerror("corrupted pointers");
X	return(0);
X}
X
X/*
X - regrepeat - repeatedly match something simple, report how many
X */
Xstatic int
Xregrepeat(p)
Xchar *p;
X{
X	register int count = 0;
X	register char *scan;
X	register char *opnd;
X
X	scan = reginput;
X	opnd = OPERAND(p);
X	switch (OP(p)) {
X	case ANY:
X		count = strlen(scan);
X		scan += count;
X		break;
X	case EXACTLY:
X		while (*opnd == *scan) {
X			count++;
X			scan++;
X		}
X		break;
X	case ANYOF:
X		while (*scan != '\0' && strchr(opnd, *scan) != NULL) {
X			count++;
X			scan++;
X		}
X		break;
X	case ANYBUT:
X		while (*scan != '\0' && strchr(opnd, *scan) == NULL) {
X			count++;
X			scan++;
X		}
X		break;
X	default:		/* Oh dear.  Called inappropriately. */
X		regerror("internal foulup");
X		count = 0;	/* Best compromise. */
X		break;
X	}
X	reginput = scan;
X
X	return(count);
X}
X
X/*
X - regnext - dig the "next" pointer out of a node
X */
Xstatic char *
Xregnext(p)
Xregister char *p;
X{
X	register int offset;
X
X	if (p == &regdummy)
X		return(NULL);
X
X	offset = NEXT(p);
X	if (offset == 0)
X		return(NULL);
X
X	if (OP(p) == BACK)
X		return(p-offset);
X	else
X		return(p+offset);
X}
X
X#ifdef DEBUG
X
XSTATIC char *regprop();
X
X/*
X - regdump - dump a regexp onto stdout in vaguely comprehensible form
X */
Xvoid
Xregdump(r)
Xregexp *r;
X{
X	register char *s;
X	register char op = EXACTLY;	/* Arbitrary non-END op. */
X	register char *next;
X	extern char *strchr();
X
X
X	s = r->program + 1;
X	while (op != END) {	/* While that wasn't END last time... */
X		op = OP(s);
X		printf("%2d%s", s-r->program, regprop(s));	/* Where, what. */
X		next = regnext(s);
X		if (next == NULL)		/* Next ptr. */
X			printf("(0)");
X		else 
X			printf("(%d)", (s-r->program)+(next-s));
X		s += 3;
X		if (op == ANYOF || op == ANYBUT || op == EXACTLY) {
X			/* Literal string, where present. */
X			while (*s != '\0') {
X				putchar(*s);
X				s++;
X			}
X			s++;
X		}
X		putchar('\n');
X	}
X
X	/* Header fields of interest. */
X	if (r->regstart != '\0')
X		printf("start `%c' ", r->regstart);
X	if (r->reganch)
X		printf("anchored ");
X	if (r->regmust != NULL)
X		printf("must have \"%s\"", r->regmust);
X	printf("\n");
X}
X
X/*
X - regprop - printable representation of opcode
X */
Xstatic char *
Xregprop(op)
Xchar *op;
X{
X	register char *p;
X	static char buf[50];
X
X	(void) strcpy(buf, ":");
X
X	switch (OP(op)) {
X	case BOL:
X		p = "BOL";
X		break;
X	case EOL:
X		p = "EOL";
X		break;
X	case ANY:
X		p = "ANY";
X		break;
X	case ANYOF:
X		p = "ANYOF";
X		break;
X	case ANYBUT:
X		p = "ANYBUT";
X		break;
X	case BRANCH:
X		p = "BRANCH";
X		break;
X	case EXACTLY:
X		p = "EXACTLY";
X		break;
X	case NOTHING:
X		p = "NOTHING";
X		break;
X	case BACK:
X		p = "BACK";
X		break;
X	case END:
X		p = "END";
X		break;
X	case OPEN+1:
X	case OPEN+2:
X	case OPEN+3:
X	case OPEN+4:
X	case OPEN+5:
X	case OPEN+6:
X	case OPEN+7:
X	case OPEN+8:
X	case OPEN+9:
X		sprintf(buf+strlen(buf), "OPEN%d", OP(op)-OPEN);
X		p = NULL;
X		break;
X	case CLOSE+1:
X	case CLOSE+2:
X	case CLOSE+3:
X	case CLOSE+4:
X	case CLOSE+5:
X	case CLOSE+6:
X	case CLOSE+7:
X	case CLOSE+8:
X	case CLOSE+9:
X		sprintf(buf+strlen(buf), "CLOSE%d", OP(op)-CLOSE);
X		p = NULL;
X		break;
X	case STAR:
X		p = "STAR";
X		break;
X	case PLUS:
X		p = "PLUS";
X		break;
X	case WORDA:
X		p = "WORDA";
X		break;
X	case WORDZ:
X		p = "WORDZ";
X		break;
X	default:
X		regerror("corrupted opcode");
X		break;
X	}
X	if (p != NULL)
X		(void) strcat(buf, p);
X	return(buf);
X}
X#endif
X
X/*
X * The following is provided for those people who do not have strcspn() in
X * their C libraries.  They should get off their butts and do something
X * about it; at least one public-domain implementation of those (highly
X * useful) string routines has been published on Usenet.
X */
X#ifdef STRCSPN
X/*
X * strcspn - find length of initial segment of s1 consisting entirely
X * of characters not from s2
X */
X
Xstatic int
Xstrcspn(s1, s2)
Xchar *s1;
Xchar *s2;
X{
X	register char *scan1;
X	register char *scan2;
X	register int count;
X
X	count = 0;
X	for (scan1 = s1; *scan1 != '\0'; scan1++) {
X		for (scan2 = s2; *scan2 != '\0';)	/* ++ moved down. */
X			if (*scan1 == *scan2++)
X				return(count);
X		count++;
X	}
X	return(count);
X}
X#endif
END_OF_FILE
if test 31244 -ne `wc -c <'regexp.c.orig'`; then
    echo shar: \"'regexp.c.orig'\" unpacked with wrong size!
fi
# end of 'regexp.c.orig'
fi
if test -f 'regexp.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regexp.h'\"
else
echo shar: Extracting \"'regexp.h'\" \(574 characters\)
sed "s/^X//" >'regexp.h' <<'END_OF_FILE'
X/*
X * Definitions etc. for regexp(3) routines.
X *
X * Caveat:  this is V8 regexp(3) [actually, a reimplementation thereof],
X * not the System V one.
X */
X#define NSUBEXP  10
Xtypedef struct regexp {
X	char *startp[NSUBEXP];
X	char *endp[NSUBEXP];
X	char regstart;		/* Internal use only. */
X	char reganch;		/* Internal use only. */
X	char *regmust;		/* Internal use only. */
X	int regmlen;		/* Internal use only. */
X	char program[1];	/* Unwarranted chumminess with compiler. */
X} regexp;
X
Xextern regexp *regcomp();
Xextern int regexec();
Xextern void regsub();
Xextern void regerror();
END_OF_FILE
if test 574 -ne `wc -c <'regexp.h'`; then
    echo shar: \"'regexp.h'\" unpacked with wrong size!
fi
# end of 'regexp.h'
fi
if test -f 'regmagic.h' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regmagic.h'\"
else
echo shar: Extracting \"'regmagic.h'\" \(153 characters\)
sed "s/^X//" >'regmagic.h' <<'END_OF_FILE'
X/*
X * The first byte of the regexp internal "program" is actually this magic
X * number; the start node begins in the second byte.
X */
X#define	MAGIC	0234
END_OF_FILE
if test 153 -ne `wc -c <'regmagic.h'`; then
    echo shar: \"'regmagic.h'\" unpacked with wrong size!
fi
# end of 'regmagic.h'
fi
if test -f 'regsub.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'regsub.c'\"
else
echo shar: Extracting \"'regsub.c'\" \(2502 characters\)
sed "s/^X//" >'regsub.c' <<'END_OF_FILE'
X/*
X * regsub
X *
X *	Copyright (c) 1986 by University of Toronto.
X *	Written by Henry Spencer.  Not derived from licensed software.
X *
X *	Permission is granted to anyone to use this software for any
X *	purpose on any computer system, and to redistribute it freely,
X *	subject to the following restrictions:
X *
X *	1. The author is not responsible for the consequences of use of
X *		this software, no matter how awful, even if they arise
X *		from defects in it.
X *
X *	2. The origin of this software must not be misrepresented, either
X *		by explicit claim or by omission.
X *
X *	3. Altered versions must be plainly marked as such, and must not
X *		be misrepresented as being the original software.
X */
X
X
X/* NOTE THIS HAS BEEN CHANGED TO WORK WITH MOO */
X/* Pattern spaces are referenced with %n instead of \n (n = 0..9) */
X/* Streams are used instead of strings */
X
X#include "regexp.h" /* CWL for moo */
X#include <stdio.h>
X#include <string.h>
X#include "regmagic.h"
X#include "streams.h"
X
X#ifndef CHARBITS
X#define	UCHARAT(p)	((int)*(unsigned char *)(p))
X#else
X#define	UCHARAT(p)	((int)*(p)&CHARBITS)
X#endif
X
X/*
X - regsub - perform substitutions after a regexp match
X */
Xvoid
Xregsub(prog, source, dest)
Xconst regexp *prog;
Xconst char *source;
X/*char *dest;*/
XStream *dest;
X{
X	register char *src;
X	register char *dst;
X	register char c;
X	register int no;
X	register int len;
X	extern char *strncpy();
X	char dstbuf[1024]; /* CWL */
X	register int cntr; /* CWL */
X
X	if (prog == NULL || source == NULL || dest == NULL) {
X		regerror("NULL parm to regsub");
X		return;
X	}
X	if (UCHARAT(prog->program) != MAGIC) {
X		regerror("damaged regexp fed to regsub");
X		return;
X	}
X
X	src = (char *)source;
X	/*dst = dest; CWL */
X	dst = dstbuf;
X	*dst = 0;
X	while ((c = *src++) != '\0') {
X		if (c == '&')
X			no = 0;
X		else if (c == '%' && '0' <= *src && *src <= '9') /* CWL */
X			no = *src++ - '0';
X		else
X			no = -1;
X 		if (no < 0) {	/* Ordinary character. */
X 			if (c == '%' && (*src == '%' || *src == '&'))
X 				c = *src++;
X 			/**dst++ = c; CWL */
X			stream_add_char(dest, c);
X 		} else if (prog->startp[no] != NULL && prog->endp[no] != NULL) {
X			len = prog->endp[no] - prog->startp[no];
X			dst = prog->startp[no];
X			for (cntr=0; cntr<len && *dst; cntr++)
X			  stream_add_char(dest, *dst++);
X			/*(void) strncpy(dst, prog->startp[no], len); */
X			/*dst += len;*/
X			/*if (len != 0 && *(dst-1) == '\0') {*/	/* strncpy hit NUL. */
X				/*regerror("damaged match string");*/
X				/*return;*/
X/*			}*/
X		}
X	}
X	/**dst++ = '\0'; CWL */
X}
END_OF_FILE
if test 2502 -ne `wc -c <'regsub.c'`; then
    echo shar: \"'regsub.c'\" unpacked with wrong size!
fi
# end of 'regsub.c'
fi
echo shar: End of shell archive.
exit 0
 
----------- cut here
-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From minos.nmt.edu!schlake Tue Feb 18 00:01:28 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <28118>; Tue, 18 Feb 1992 00:01:19 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11716>; Tue, 18 Feb 1992 00:00:56 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11705>; Mon, 17 Feb 1992 23:57:11 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 17 Feb 1992 23:46:26 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11701>; Mon, 17 Feb 1992 23:45:53 PST
Received: from minos.nmt.edu ([129.138.1.5]) by alpha.xerox.com with SMTP id <11702>; Mon, 17 Feb 1992 23:45:12 PST
Received: by minos.nmt.edu
	(16.6/15.6) id AA05434; Tue, 18 Feb 92 00:45:09 -0700
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
X-NS-Transport-ID: 08002008D0FD0017C3A3
Message-ID: <9202180745.AA05434@minos.nmt.edu>
Date:	Mon, 17 Feb 1992 23:45:08 -0800
From:	schlake@minos.nmt.edu (Schlake)
To:	moo-cows.PARC@xerox.com
Subject: suspend()

As suspend() stands now, it only returns if it has an error.  It is
basically the same function as a sleep() call, only the sleep call has a
provision to return how much it was off by when it returns.  If a sleep()
is 3 seconds late in returning, then it returns -3, and if it is a second
early, it returns a 1.  I know suspend() is subject to missing cause of
server lag, and a return value to indicate how much it missed by would be
nice.  Any comments?


                                                        Schlake

From silver.cs.umanitoba.ca!charlto Thu Mar  5 12:45:32 1992
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Thu, 5 Mar 1992 12:45:24 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11909>; Thu, 5 Mar 1992 12:44:37 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11616>; Thu, 5 Mar 1992 12:39:46 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 5 Mar 1992 12:35:17 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11719>; Thu, 5 Mar 1992 12:34:49 PST
Received: from ccu.UManitoba.CA ([130.179.16.8]) by alpha.xerox.com with SMTP id <11946>; Thu, 5 Mar 1992 12:22:08 PST
Received: from silver.cs.UManitoba.CA by ccu.UManitoba.CA
	(4.1/25-eef) id AA01249; Thu, 5 Mar 92 14:22:36 CST
Received:  by silver.cs.UManitoba.CA
	(4.1/25-eef) id AA26392; Thu, 5 Mar 92 14:24:28 CST
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	Michael K.Charlton <charlto@silver.cs.UManitoba.CA>
		^	 ^-illegal period in phrase
		 \-phrases containing '.' must be quoted
X-NS-Transport-ID: 08002008D0FD0018C951
Message-ID: <9203052024.AA26392@silver.cs.UManitoba.CA>
Date:	Thu, 5 Mar 1992 12:24:28 -0800
From:	charlto@silver.cs.umanitoba.ca
To:	moo-cows.PARC@xerox.com
Subject: LP Base MOO

Hello all.  My brother and I have been working on writing a MOO
database (straight from the minimal.db) that provides a user interface
similar to LP MUD.  The reasons for this are varied.  We liked LP
MUD's, but one major problem with them is that they crash rather
frequently.  We thought that designing an LP style interface for MOO
would be fairly easy, so we went at it.  My brother did most of the
work (as I sat back with a few beers and "supervised") and after 3 months
we believe we now have something stable enough to show people.  If you
are interested in taking a look at this beast, send me some mail and I
will give you a player on the system.  Please be warned that there is
virtually nothing in the system (just the temple, pub, shops and a
cave full of orcs).  This is NOT a playable game.  It is a development
system that we are opening up to selected individuals for comments.
Our main goal in inviting people on the system is to uncover bugs and
incompatabilities between our system (tentatively called LP Base) and
real LP.  We are also looking for MOO programmers who are interested
in helping us implement a new type of MUD based on the LP Base DB
(especially if you are interested in writing autonomous monster bots).
                  Mike
                  charlto@silver.cs.umanitoba.ca

From phantom.com!dead Fri Mar 13 20:23:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "13" "March" "1992" "20:12:00" "-0800" "Dead Lord" "dead@phantom.com " nil "16" "" "^Date:" nil nil "3"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 13 Mar 1992 20:23:24 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11836>; Fri, 13 Mar 1992 20:22:50 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11833>; Fri, 13 Mar 1992 20:18:08 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 13 Mar 1992 20:13:12 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11764>; Fri, 13 Mar 1992 20:12:48 PST
Received: from phantom.com ([38.145.218.226]) by alpha.xerox.com with SMTP id <11764>; Fri, 13 Mar 1992 20:12:13 PST
Received: by phantom.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0lPQ72-0003rdC@phantom.com>; Fri, 13 Mar 92 23:12 EST
X-NS-Transport-ID: 08002008D0FD00194B32
Message-ID: <m0lPQ72-0003rdC@phantom.com>
Date:	Fri, 13 Mar 1992 20:12:00 -0800
From:	dead@phantom.com (Dead Lord)
To:	moo-cows.PARC@xerox.com

Perhaps someone can answer a few questions I have.  I've read over the Moo
documentation and it seems to be an excellent system for designing a mud.
So WHY is it that there is one Moo and a few hundred LPmuds, TinyM*, Diku-
muds, UnterMuds?  I believe Moo is runtime a interpreted language, which would
make it somewhat slow.  Are the other system compiled, speeding them up?
Or is their some other techinical reason?  IS there in fact a better, faster
or more flexible system for running a mud with?

Thank you
dead@phantom.com

One more thing, what sort of system is LambdaMoo running on and how well does
it treat the processor. Is the LambdaMoo a dedicated machine which is only
running moo?

thanks

From phantom.com!dead Sat Mar 14 00:35:13 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "14" "March" "1992" "00:09:00" "-0800" "Dead Lord" "dead@phantom.com " nil "10" "" "^Date:" nil nil "3"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sat, 14 Mar 1992 00:35:06 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11647>; Sat, 14 Mar 1992 00:34:22 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11650>; Sat, 14 Mar 1992 00:32:02 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 14 Mar 1992 00:28:43 -0800
Received: from uu.psi.com ([136.161.128.3]) by alpha.xerox.com with SMTP id <11689>; Sat, 14 Mar 1992 00:28:23 PST
Received: from phantom.com by uu.psi.com (5.65b/4.1.011392-PSI/PSINet)
	id AA19773; Sat, 14 Mar 92 03:18:30 -0500
Received: by phantom.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0lPTne-0003jyC@phantom.com>; Sat, 14 Mar 92 03:09 EST
X-NS-Transport-ID: 08002008D0FD00194C5F
Message-ID: <m0lPTne-0003jyC@phantom.com>
Date:	Sat, 14 Mar 1992 00:09:00 -0800
From:	dead@phantom.com (Dead Lord)
To:	moo-cows@parc.xerox.com

Perhaps someone can answer a few questions I have.  I've read over the Moo
documentation and it seems to be an excellent system for designing a mud.
So WHY is it that there is one Moo and a few hundred LPmuds, TinyM*, Diku-
muds, UnterMuds?  I believe Moo is runtime a interpreted language, which would
make it somewhat slow.  Are the other system compiled, speeding them up?
Or is their some other techinical reason?  IS there in fact a better, faster
or more flexible system for running a mud with?

Thank you
dead@phantom.com

From morticia.cnns.unt.edu!cluther Mon Mar 16 09:50:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "March" "1992" "09:32:32" "-0800" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "44" "Reply to Dead Lord" "^Date:" nil nil "3"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29572>; Mon, 16 Mar 1992 09:50:23 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11643>; Mon, 16 Mar 1992 09:47:23 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11605>; Mon, 16 Mar 1992 09:38:13 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 16 Mar 1992 09:33:02 -0800
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11604>; Mon, 16 Mar 1992 09:32:40 PST
Received: by morticia.cnns.unt.edu id AA23990
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Mon, 16 Mar 1992 11:32:33 -0600
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD00195AE7
Message-ID: <199203161732.AA23990@morticia.cnns.unt.edu>
Date:	Mon, 16 Mar 1992 09:32:32 -0800
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Reply to Dead Lord

Dead Lord (>) writes:
> 
> Perhaps someone can answer a few questions I have.  I've read over the Moo
> documentation and it seems to be an excellent system for designing a mud.
> So WHY is it that there is one Moo and a few hundred LPmuds, TinyM*, Diku-
> muds, UnterMuds?  I believe Moo is runtime a interpreted language, which would
> make it somewhat slow.  Are the other system compiled, speeding them up?
> Or is their some other techinical reason?  IS there in fact a better, faster
> or more flexible system for running a mud with?
> 
> Thank you
> dead@phantom.com
> 
> One more thing, what sort of system is LambdaMoo running on and how well does
> it treat the processor. Is the LambdaMoo a dedicated machine which is only
> running moo?

Well, the Moo is closer to LP (and diku, I assume) than it is to the Tinies
(except for the newer tinies like Muck.)

I suspect the only reason you don't see any Moos is that they are daftly hard
to build.

For example, I could set up a LP mud today and people could connect to it and
play.  Now, this would be a basic LP, but so many people play LP and there's so much "canned" stuff for LP that its just really easy to set up.

Moo, however, forces you to build a great deal.  Therefore, I suspect that Moos
are only even considered by people who know that in N months time the 
computer resources that house the Moo will still be around.

We have been building the GodNet for almost 6 months now, maybe a little
longer.  It is an immenently tedious process (recently made less so by the
acquisition of the emacs moo client :) ), but probably worth it in the long 
run.  We are just about to open (in 1 week, so we've planned).

Fortunately, it appears that Moo is fairly kind to the machine it is running
on, only demanding, at intervals, a great deal of memory to back itself up 
(by great deal I mean an entire copy of the db to write to disk).

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From onet.edu!camp!seth Tue Apr 28 10:29:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "06:06:00" "-0700" "seth%camp@onet.edu" "seth%camp@onet.edu" nil "31" "$player and $prog and suchlike." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Tue, 28 Apr 1992 10:29:48 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11931>; Tue, 28 Apr 1992 10:28:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11865>; Tue, 28 Apr 1992 10:22:13 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 10:13:19 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11925>; Tue, 28 Apr 1992 10:10:19 PDT
Received: from suna.osc.edu ([128.146.1.4]) by alpha.xerox.com with SMTP id <11923>; Tue, 28 Apr 1992 10:08:06 PDT
Received: from camp.Onet.EDU ([141.110.32.5]) by suna.osc.edu (5.65c/pl1+KVa/OSC-3.00)
	id AA18179; Tue, 28 Apr 1992 13:08:01 -0400
Received: from campgate.onet.edu by  camp.Onet.EDU (4.1/SMI-4.1)
	id AA11615; Tue, 28 Apr 92 13:08:01 EDT
Received: by campgate.onet.edu with Network-Courier
	id <29FD862E@campgate.onet.edu>; Tue, 28 Apr 92 13:06:54
X-Mailer: Network Courier V2.1a
Encoding: 31 TEXT
X-NS-Transport-ID: 08002008D0FD001BDC4A
Message-ID: <29FD862E@campgate.onet.edu>
Date:	Tue, 28 Apr 1992 06:06:00 -0700
From:	seth%camp@onet.edu
To:	moo-cows.parc@xerox.com
Subject: $player and $prog and suchlike.

Okay.  We've got $player, which has certain limited abilities, and we've got 
$prog which pretty much has everything.  There are other classes out there 
which have more features and handier utilities, but when ya get down to it 
everything that's needed is on $prog.

Is there any reason there couldn't be another class?  Say something like 
$builder?  It could be between $player and $prog, and it could have a more 
robust @create (with $player's create pared down, say, to only allow generic 
players to create $rooms and $things and $containers and so forth).  One 
would need to be a $builder in order to create other things.  Just a thought.

Another thought relates to allowing non-programmers a @chparent which lets 
them use other player classes.  For example, and I know this is a heinous 
example, there are way too many people who want to be Schmoos.  (And, I know, 
I am speaking here specifically of LambdaMOO and not generally, but sue me if 
you don't like it.)  These people who want to be Schmoos will get a $prog 
bit, @chparent to Schmoo, and not understand a damned thing they've just 
done.  An alternative would be to allow the non-programmer to @chparent to 
any player class, and let them suffer the consequences if they can't use the 
programmer-only verbs.

I'm just tossing out ideas, mainly for two reasons:
+ I want to get SOMETHING on Moo-Cows which isn't a request to be on
  Moo-Cows, and
+ I really am interested in what people think about having something
  -different- from the usual $player and $prog pairs.  There's got to
  be -something- besides $player and $prog and $wiz, right?  I wanna hear
  ideas.  (Not that I can -implement- any of them. Heh. But we can talk.)

Blackbriar


From ee.ualberta.ca!daum Tue Apr 28 21:38:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "21:24:44" "-0700" "Tanya Louise Daum" "daum@ee.ualberta.ca" nil "35" "HP-SUX versus MOO" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 28 Apr 1992 21:37:59 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12018>; Tue, 28 Apr 1992 21:36:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11982>; Tue, 28 Apr 1992 21:32:21 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 21:26:49 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11583>; Tue, 28 Apr 1992 21:26:24 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11583>; Tue, 28 Apr 1992 21:25:12 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA21973; Tue, 28 Apr 92 22:24:44 -0600
X-NS-Transport-ID: 08002008D0FD001BE769
Message-ID: <92Apr28.212512pdt.11583@alpha.xerox.com>
Date:	Tue, 28 Apr 1992 21:24:44 -0700
From:	Tanya Louise Daum <daum@ee.ualberta.ca>
To:	moo-cows.parc@xerox.com
Subject: HP-SUX versus MOO


	I'm having problem compiling MOO on my HP9000-830 account here.  I have
permission from my Sysadmin to set up a MOO here, and it really irks me that my
C skills bite so bad.

	I'm having problems with Malloc.  I originally had -DUSE_SYSTEM_MALLOC
but that bombed out on me (sorry, can't come up with the specific message, just
that it couldn't allocate space when I booted Minimal.db or LambdaCore)

	So I switched to the gnu-malloc.  It compiles fine and all, but it does
one of two things:

		If I boot minimal.db, it loads the database fine, but when I
telnet into it, it says "*** Shutting down : server panic ***" looking
Minimal.log I see : Panic, caught signal -11, and bad argument to free (or
something, I would merge it in, but I haven't figured that out in Emacs yet :-)
)

	If I boot LambdaCore, after it loads it says "*** Panic: p" ...
whatever that means.

	I wanted to use my debugger, but "as" chokes on anything I feed into it
when I have the -g flag in gcc on.  I tried using cc, but I can't get MOO to
compile with it ... massive syntax errors and such.

	I am not a C expert.  My MOO programming skills aren't bad, and I don't
want to be blasted for being a nitwit and not deserving a MOO in the first
place.  I am simply asking if anybody else has had problems with gnu-malloc on
HPUX or any other platform, I think this is the root of the problem.

	So please, if you can help me, *help* me.  (sigh)

	Thanks.

-Opiate-

From minos.nmt.edu!schlake Tue Apr 28 21:47:08 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "21:39:11" "-0700" "Schlake" "schlake@minos.nmt.edu " nil "8" "Re: HP-SUX versus MOO" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 28 Apr 1992 21:47:03 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12041>; Tue, 28 Apr 1992 21:45:38 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11996>; Tue, 28 Apr 1992 21:42:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 21:40:59 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12003>; Tue, 28 Apr 1992 21:40:35 PDT
Received: from minos.nmt.edu ([129.138.1.5]) by alpha.xerox.com with SMTP id <11583>; Tue, 28 Apr 1992 21:39:57 PDT
Received: by minos.nmt.edu
	(16.6/15.6) id AA27389; Tue, 28 Apr 92 22:39:12 -0600
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
X-NS-Transport-ID: 08002008D0FD001BE789
In-Reply-to: "Tanya Louise Daum <daum@ee.ualberta.ca>
       \"HP-SUX versus MOO\" (Apr 28,  9:24pm)in"
Message-ID: <9204290439.AA27389@minos.nmt.edu>
Date:	Tue, 28 Apr 1992 21:39:11 -0700
From:	schlake@minos.nmt.edu (Schlake)
To:	Tanya Louise Daum <daum@ee.ualberta.ca>, moo-cows.parc@xerox.com
Subject: Re: HP-SUX versus MOO

I use an HP 9000/835, and I know a lot of the problems.  First off, GCC is
a bad idea, cause I don't think that any port out there works.  Some of
them come close, but none really work.  HPUX is a SYSV and MOO was made
for BSD, and HPUX doesn't like BSD things.  Send me more specific things
(like logs of compiling, etc) and I'll see what I can figure out.


-- void *(*(*schlake())[])(void *);

From uqeve.cc.uq.oz.au!DPMT Tue Apr 28 22:32:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "13:25:38" "-0700" "\"I don't want the world, I just want your half\"" "DPMT@uqeve.cc.uq.oz.au" nil "34" "Excessive programmer privileges" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 28 Apr 1992 22:31:53 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12022>; Tue, 28 Apr 1992 22:31:14 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11750>; Tue, 28 Apr 1992 22:28:35 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 22:26:26 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12003>; Tue, 28 Apr 1992 22:26:11 PDT
Received: from bunyip.cc.uq.oz.au ([130.102.128.1]) by alpha.xerox.com with SMTP id <12003>; Tue, 28 Apr 1992 22:25:56 PDT
Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP) 
          id <04352-0@bunyip.cc.uq.oz.au>; Wed, 29 Apr 1992 15:25:38 +0000
Received: from uqeve.decnet.uq.oz.au by BUNYIP.DECnet 
          with MAIL-11 (utk-mail11d v1.6); Wed, 29 Apr 92 15:25:38 EST
X-To: BUNYIP::"moo-cows@xerox.com"
X-NS-Transport-ID: 08002008D0FD001BE7E7
Message-ID: <92Apr28.222556pdt.12003@alpha.xerox.com>
Date:	Wed, 29 Apr 1992 13:25:38 -0700
From:	"I don't want the world, I just want your half" <DPMT@uqeve.cc.uq.oz.au>
To:	moo-cows.parc@xerox.com
Subject: Excessive programmer privileges


The inclusion of a class `midway' between $player and $prog seems like a
reasonable idea to me. I've never been entirely happy with the current system
of "hand a prog bit to anyone who asks". When I first started playing Lambda,
I was at least asked what I was planning on building and whether I felt I could
contribute anything of worth to the game. The threat of not having rooms linked
to the main house seemed to _mean_ something then.

Now, prog bits are handed out almost the instant the new player steps out of
the closet. I understand and empathise with the problems associated;  wizards
just _don't_ have the time to interrogate every new player who hassles them
for a programmer bit. However, there are a large number of players who are
given these bits when they haven't even fleshed out their characters...
descriptions and genders are left unset, several junk items are created, then
the character disappears, never to be heard from again. Groups of people get
together and build their only little mini-areas, with no concern for the main
theme at all. People will be requesting prog bits now just to gain more quota
(I could be talking through my hat here...I'm assuming that players are
granted more quota once they've been given programmer status).

Having a programmer bit signifies nothing anymore. Do not misinterpret me, I'm
not suggesting that prog bits become an `elitist' symbol. I just feel that 
having a programmer bit should indicate a willingness to contribute worthwhile
areas to Lambda, to aid in making grow. Interest in Lambda seems to wane very
quickly merely because nothing _ever_ changes...

Lambda lacks direction, more now that it ever did before. Theme issues seem to 
be entirely forgotten. Growth has practically ceased. In my opinion, a small
core of programmers with a clear idea of what can be accomplished within theme
would be infinitely more benefitial than a multitude of people all thrusting
their chaotic concepts into the house.


Morpheus

From wvnvaxa.wvnet.edu!UN037475 Tue Apr 28 22:57:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "22:50:17" "-0700" "\"I was trying to daydream, but my mind kept wandering\"" "UN037475@wvnvaxa.wvnet.edu" nil "16" "Programmer bits and theme and clutter" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 28 Apr 1992 22:57:26 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12039>; Tue, 28 Apr 1992 22:56:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12022>; Tue, 28 Apr 1992 22:53:58 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 22:51:46 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12006>; Tue, 28 Apr 1992 22:51:20 PDT
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12006>; Tue, 28 Apr 1992 22:50:31 PDT
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #041B1) id
 <01GJEHV5VHA895NJDY@WVNVMS.WVNET.EDU>; Wed, 29 Apr 1992 01:50:17 EDT
X-VMS-To: IN%"moo-cows.parc@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD001BE81A
Message-ID: <01GJEHV5VHAA95NJDY@WVNVMS.WVNET.EDU>
Date:	Tue, 28 Apr 1992 22:50:17 -0700
From:	"I was trying to daydream, but my mind kept wandering" <UN037475@wvnvaxa.wvnet.edu>
To:	moo-cows.parc@xerox.com
Subject: Programmer bits and theme and clutter

I was under the impression that LambdaMOO was more of a 'test-site' for the MOO
system/language, and as such was oriented toward giving _everyone_ the chance
to program/build/what have you.  I don't like the utter chaos any more than
anyone else - it's certainly the most disorganized MUD I've ever seen - but at
the same time the free availability of programmer bits makes a good atmosphere
for learning the MOO language and good coding/design techniques in general. 
It's unfortunate that so few (if any?) other MOOs have been set up; this might
provide a nice way for people to put into application the MOO programming
skills they get from Lambda, in a more focused way.

Basically I don't think limiting prog bits is that good an idea on Lambda; I'm
not sure _I_ would have gotten one if things had been more limited.  But I'm
certainly glad I did.


Gilmore

From judy.indstate.edu!ajax Tue Apr 28 23:04:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "22:58:44" "-0700" "Mitenka Nezhlyudov" "ajax@judy.indstate.edu " nil "7" "Re:  Excessive programmer privileges" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 28 Apr 1992 23:04:28 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12039>; Tue, 28 Apr 1992 23:03:48 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12009>; Tue, 28 Apr 1992 23:00:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 22:58:53 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12030>; Tue, 28 Apr 1992 22:56:25 PDT
Received: from judy.indstate.edu ([139.102.14.10]) by alpha.xerox.com with SMTP id <12038>; Tue, 28 Apr 1992 22:55:22 PDT
Received: by judy.indstate.edu (5.61/1.35)
	id AA24690; Wed, 29 Apr 92 00:58:44 -0500
X-NS-Transport-ID: 08002008D0FD001BE820
Message-ID: <9204290558.AA24690@judy.indstate.edu>
Date:	Tue, 28 Apr 1992 22:58:44 -0700
From:	ajax@judy.indstate.edu (Mitenka Nezhlyudov)
To:	DPMT@uqeve.cc.uq.oz.au, moo-cows.parc@xerox.com
Subject: Re:  Excessive programmer privileges

I'm apt to agree with morpheus. Small amounts of programmers might be more
beneficial to any MUD, as well as easier on the system. Johnny-come-lately
programmers are apt to create half of a world and leave it to rot...or perhaps
to create some "secret" world that nobody but himself and his friends can enter.

Mitenka
(Osiris)

From ecsuc.ctstateu.edu!PLUMMERS Tue Apr 28 23:30:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "23:25:50" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "17" "programmer's" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 28 Apr 1992 23:30:01 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11625>; Tue, 28 Apr 1992 23:28:38 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12042>; Tue, 28 Apr 1992 23:26:40 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 28 Apr 1992 23:25:04 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12006>; Tue, 28 Apr 1992 23:24:35 PDT
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <12006>; Tue, 28 Apr 1992 23:23:46 PDT
X-Vmsmail-To: SMTP%"moo-cows.parc@xerox.com"
X-NS-Transport-ID: 08002008D0FD001BE860
Message-ID: <920429022550.2020f903@ECSUC.CTSTATEU.EDU>
Date:	Tue, 28 Apr 1992 23:25:50 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	moo-cows.parc@xerox.com
Subject: programmer's

    I agree with morpheus, but I think that a MOO allows for something grand...
for a person to allow another to delve into their imagination, and play. This
is well beyond the confines of the Lambda house, and until someone gets smart
and makes a spot for imagination, you will have the majority of objects "in
limbo" (like a mirror that opens a portal into the "reverse world").
     Friends like to join things together, mainly because it is more natural
to walk then teleport, but the Lambda house is so cluttered, and confused, you
can be in a dark corner of the house, walk north, and be in a diamond room.
     One more thing....other MOO's are bound to fail. I know from experience.
We planned a outdoor, mountain type MOO...as soon as people came in they 
made unreal rooms, and things that didn't fit, just like in Lambda. 
Organization is impossible for newcomers, unless they rip out the teleport
command, and force programmers to make realism. And there goes half the fun
down the tubes.....
     

                           Saruman

From gnu.ai.mit.edu!feoh Wed Apr 29 00:21:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "April" "1992" "20:15:32" "-0700" "Chris Patti" "feoh@gnu.ai.mit.edu " nil "25" "$prog , $player, and everything in between" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 29 Apr 1992 00:21:38 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11625>; Wed, 29 Apr 1992 00:21:07 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11577>; Wed, 29 Apr 1992 00:18:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 00:16:51 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11577>; Wed, 29 Apr 1992 00:16:24 PDT
Received: from churchy.gnu.ai.mit.edu ([128.52.46.32]) by alpha.xerox.com with SMTP id <11535>; Wed, 29 Apr 1992 00:15:49 PDT
Received: by churchy.gnu.ai.mit.edu (5.65/4.0)
	id <AA18870@churchy.gnu.ai.mit.edu>; Wed, 29 Apr 92 03:15:34 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD001BE8BA
Message-ID: <9204290715.AA18870@churchy.gnu.ai.mit.edu>
Date:	Tue, 28 Apr 1992 20:15:32 -0700
From:	feoh@gnu.ai.mit.edu (Chris Patti)
To:	moo-cows.parc@xerox.com
Subject: $prog , $player, and everything in between

I also agree with Morpheus that an elite core of programmers would be more
beneficial to the MOO in general...

However: I'll admit that *I* would not be entirely pleased at having my $prog
wings clipped.

I don't do tons of programming on the MOO because I feel my brain is taxed 
enough already with other things, *However* I would be very disappointed indeed
if, in situations where I wanted ot to be there, it wasn't allowed.   For
example: I have a custom confunc/disfunc pair..  I have my own (slightly.. oh..
deranged? :) version of dress/undress/strip.  These are by no means major 
accomplishments, I wouldn't have been allowed into any kind of 'elite core'
of programmers.

In a couple of cases the people agreeing with Morpheus may very well fall into
the same category.

While I think Morpheus' idea is a very good one which deserves much merit and
careful thought, I'll leave you all with this: Do *you* want your wings 
clipped?
 

     Sincerely
         -Feoh


From rsch.oclc.org!stu Wed Apr 29 04:48:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "04:38:09" "-0700" "Stu Weibel" "stu@rsch.oclc.org " nil "8" "Re:  Excessive programmer privileges" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 29 Apr 1992 04:48:41 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11885>; Wed, 29 Apr 1992 04:45:35 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11873>; Wed, 29 Apr 1992 04:43:04 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 04:40:13 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11870>; Wed, 29 Apr 1992 04:39:40 PDT
Received: from rsch.oclc.org ([132.174.1.2]) by alpha.xerox.com with SMTP id <11870>; Wed, 29 Apr 1992 04:39:14 PDT
Received: from seneca.rsch.oclc.org by rsch.oclc.org (4.1/2.890906)
	id AA24702; Wed, 29 Apr 92 07:36:07 EDT
Return-Path: stu@rsch.oclc.org
Received: by seneca.rsch.oclc.org (4.1/2.890906)
	id AA08755; Wed, 29 Apr 92 07:38:09 EDT
X-NS-Transport-ID: 08002008D0FD001BEA3B
Message-ID: <9204291138.AA08755@seneca.rsch.oclc.org>
Date:	Wed, 29 Apr 1992 04:38:09 -0700
From:	stu@rsch.oclc.org (Stu Weibel)
To:	moo-cows.parc@xerox.com
Subject: Re:  Excessive programmer privileges


> Johnny-come-lately programmers are apt to create half of a world and leave it to rot...

Whew, Pavel's desk must really smell bad with all them rotting bits lying around.

Are some of you folks taking this just a [rotting] bit too seriously?

- a johnny-come-lately

From morticia.cnns.unt.edu!cluther Wed Apr 29 09:00:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "08:51:31" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "36" "Re: Excessive programmer privileges" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 09:00:55 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12051>; Wed, 29 Apr 1992 08:59:22 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11920>; Wed, 29 Apr 1992 08:55:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 08:52:44 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11937>; Wed, 29 Apr 1992 08:52:00 PDT
Received: by morticia.cnns.unt.edu id AA21660
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Wed, 29 Apr 1992 10:51:33 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001BED6C
In-Reply-to: "<92Apr28.222556pdt.12003@alpha.xerox.com>; from \"I don't want the world, I just want your half\" at Apr 29, 92 1:25 pm"
Message-ID: <199204291551.AA21660@morticia.cnns.unt.edu>
Date:	Wed, 29 Apr 1992 08:51:31 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	DPMT@uqeve.cc.uq.oz.au (I don't want the world I just want your half)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Excessive programmer privileges

I don't want the world, I just want your half (>) writes:
> 
> 
> The inclusion of a class `midway' between $player and $prog seems like a
> reasonable idea to me. I've never been entirely happy with the current system
> of "hand a prog bit to anyone who asks". When I first started playing Lambda,
> I was at least asked what I was planning on building and whether I felt I could
> Lambda lacks direction, more now that it ever did before. Theme issues seem to 
> be entirely forgotten. Growth has practically ceased. In my opinion, a small
> core of programmers with a clear idea of what can be accomplished within theme
> would be infinitely more benefitial than a multitude of people all thrusting
> their chaotic concepts into the house.

On the GodNet, we originally removed the concept of players having programmer
bits (aka Lambda) precisely because we didn't want people coming in, making
buggy junk, and leaving us with a handful of worthless objects and a bloated
database.

However, as our opinions mellowed, it became somewhat clear that a good reward
for players would be having a builder level, where the player gets a programming
bit.  This would not use the $prog, but rather, just allow the builder player
to build and program a small collection of objects.  They still would not get
"magical" abilties like being able to teleport or see and get things from 
afar.  The, would, however, have status in the GodNet, whether they be clergy,
canon officals, experienced hackers, whatever.

Lastly, if your tired of Lambda and its themelessness, let me plug the GodNet
here, which is going to open RSN (yes yes, I know we *always* say RSN, but
we mean it ;)).  Definitely a strongly themed mud/moo, and we have no
sympathy or empathy for players who can't live within that theme.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From parc.xerox.com!masinter Wed Apr 29 09:07:40 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "08:53:59" "-0700" "Larry Masinter" "masinter@parc.xerox.com" nil "57" "Re:  Excessive programmer privileges" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 09:07:29 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12055>; Wed, 29 Apr 1992 09:05:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11989>; Wed, 29 Apr 1992 09:01:59 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 08:58:35 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12050>; Wed, 29 Apr 1992 08:55:52 PDT
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11937>; Wed, 29 Apr 1992 08:54:18 PDT
Received: by poplar.parc.xerox.com id <101795>; Wed, 29 Apr 1992 08:54:11 -0700
Fake-Sender: masinter@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001BED69
Message-ID: <92Apr29.085411pdt.101795@poplar.parc.xerox.com>
Date:	Wed, 29 Apr 1992 08:53:59 -0700
From:	Larry Masinter <masinter@parc.xerox.com>
To:	moo-cows.PARC@xerox.com
Subject: Re:  Excessive programmer privileges

The problem with setting up finer distinctions in the rankings between
player and wizard is that it is yet another thing to establish policy
about, make decisions, and administer. 

Of course you have to make policy decisions, but it would be better to
reduce the number of policy decisions that have to be made. ("Should
we give this guy programmer privs, or more quota?") 

In addition, fine grain distinctions in the object hierarchy between
$player and $wiz can lead to a lot of headaches, moving verbs up and
down the hierarchy.

I had a couple of different ideas; they seem to go together, but might
be considered independently:
(a) have only $player and $wizard (with no .programmer bit)
    but CHARGE QUOTA FOR VERBS

(b) move more player-class verbs for building to features.

================================================================
a) charge quota for verbs
The basic idea is to reduce the administration overhead by letting the
individual decide whether their quota should be spent on objects or
verbs. The idea would be that players wouldn't have enough quota
initially to write any verbs. As their quota increased, they could
either build things or write verbs; the policy-makers could decide
however they want which is more socially-redeeming and deserving of
more quota. I would guess that some kind of sliding scale for verbs
would make sense, e.g., first verb costs 5 quota points, second one 3
and then they are 1 quota point thereafter. Of course, the quota
policy would have to be adjusted to take into account that some quota
is spent on verbs as well as objects. You might want to reduce the
quota-for-verb charge to 0 for prolific builders.
================================================================
b) move more verbs to 'features', especially those that 'would confuse
novices'. You can add features as you understand them, remove them,
etc., without sliding up and down and around the object hierarchy.

This is the only simple way I can see of reducing the 'player class'
confusion, which is to let people pick features as they want them.

There are a couple of technical problems with features that would have
to be addressed, e.g., allow features with !x verbs, let features keep
state on players, but I think those are solvable.

This is a poor substitute for multiple inheritance, but I think it
will do.











From cheetah.math.oxy.edu!t_pascal Wed Apr 29 09:41:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "09:29:55" "-0700" "C. Regis Wilson" "t_pascal@cheetah.math.oxy.edu " nil "50" "prog bits" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 09:41:54 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12057>; Wed, 29 Apr 1992 09:38:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12053>; Wed, 29 Apr 1992 09:34:32 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 09:31:58 -0700
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <12058>; Wed, 29 Apr 1992 09:30:57 PDT
Received: by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA04491; Wed, 29 Apr 92 09:29:55 PDT
Received: by NeXT Mailer (1.63)
X-NS-Transport-ID: 08002008D0FD001BEE31
Message-ID: <9204291629.AA04491@cheetah.math.oxy.edu>
Date:	Wed, 29 Apr 1992 09:29:55 -0700
From:	t_pascal@cheetah.math.oxy.edu (C. Regis Wilson)
To:	moo-cows@parc.xerox.com
Subject: prog bits

 I agree with all that has been discussed recently. 

However, the problem can be solved (I think) with some
careful preparation.  For instance, the moo I planning
will have a large area.  There will be a downtown, a
residential area, etc.  If the wizards keep the link
abilities correctly, no one will be able to link,  
except
where they need to.

For instance, I have a network of streets, and vacant  
lots
along the sides.  Users may get lots and houses, the  
only
stipulation is that they have some "normal" exterior. 

(That is, a house, or a hut, or something, not a  
shimmering
portal, etc.)  Then, they can build their own houses  
and do
whatever they will do.

Of course, you will accuse me now of isolationism, and
people will only make things for themselves and their
friends.  This is true, but misleading because I'm  
still
working on the moo, and I have not tested my theories  
with
real users.

Well, I also agree that an extra step between $prog and
$player would be a good idea.  Of course, I am not  
going to be
the first to jump in and change either the server or  
db.  If
someone does it, I'm sure wizards everywhere will scoop
it up.
---

---------
T. Pascal, King of Pascal          | "He travels  
fastest who travels alone,
1600 Campus Road, Box 829          | but not when the  
frost drops below zero
Los Angeles, CA 90041              | fifty degrees or  
more."
                                   |         -Old  
eskimo saying
...!gate.oxy.edu!t_pascal  
t_pascal@{cub.math,jaguar.math,bobcat,tiger}.oxy.edu

From uqeve.cc.uq.oz.au!DPMT Wed Apr 29 10:01:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "00:45:52" "-0700" "\"Morpheus (who doesn't want the world...)\"" "DPMT@uqeve.cc.uq.oz.au" nil "39" "Further ramblings..." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Wed, 29 Apr 1992 10:01:02 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12071>; Wed, 29 Apr 1992 09:57:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12054>; Wed, 29 Apr 1992 09:54:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 09:47:42 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11930>; Wed, 29 Apr 1992 09:47:14 PDT
Received: from bunyip.cc.uq.oz.au ([130.102.128.1]) by alpha.xerox.com with SMTP id <12049>; Wed, 29 Apr 1992 09:46:14 PDT
Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP) 
          id <15592-0@bunyip.cc.uq.oz.au>; Thu, 30 Apr 1992 02:45:52 +0000
Received: from uqeve.decnet.uq.oz.au by BUNYIP.DECnet 
          with MAIL-11 (utk-mail11d v1.6); Thu, 30 Apr 92 02:45:52 EST
X-To: BUNYIP::"moo-cows@xerox.com"
X-NS-Transport-ID: 08002008D0FD001BEE6F
Message-ID: <92Apr29.094614pdt.12049@alpha.xerox.com>
Date:	Thu, 30 Apr 1992 00:45:52 -0700
From:	"Morpheus (who doesn't want the world...)" <DPMT@uqeve.cc.uq.oz.au>
To:	moo-cows.PARC@xerox.com
Subject: Further ramblings...


This followup is mostly in response to Saruman's posting...

Firstly, he mentions waiting for someone to get "smart and make[s] a spot for
imagination". It is this unrestricted/undirected building that I am most 
strongly objecting to. I don't consider the "wonderful" creations hanging in
$nothing to be particularly imaginative...quite the reverse in fact. The objects
and areas which I _most_ appreciate are those that are cleverly integrated into
the theme of the LambdaHouse itself. This shows ingenuity (IMHO).

Next, he states that people often "like to join things together, mainly because
it is more natural to walk then teleport". However, this is obviously not the
case, as the rampant use of teleport rings and the move of @go/@join to $player
seem to indicate.

Finally, Saruman states that other MOO's are "bound to fail" due to the fact
that new people don't stick to the theme. What I would like to see is a MOO
where the players have _no_ building/creating commands at all. The emphasis 
would be on roleplay, not on who can build the cleverest gadget of the month.
If people don't want to play within a theme, then there is no reason for them
to continue visiting the MOO.

(Saruman, please note that I'm not flaming you, I'm just using your message
to clear up some points).

I realize that Lambda always has been an "experimental" MOO, and I suppose this
wouldn't bother me so much if there were more MOOs up that offered what I'm
looking for. I'm definately not advocating the "clipping of wings" at all, I'm
just suggesting a reavaluation of the approach taken to setting up a MUD.

Well, I've forgotten what my point was. It's 3am and my mind is still juggling
my latest C assignment. If anyone is interested in further discussing of this
and other theme issues, might I suggest we take it to the *themes mail group
on Lambda?

It's been a long night.


Morpheus

From morticia.cnns.unt.edu!cluther Wed Apr 29 10:34:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "10:19:13" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "17" "Re: Further ramblings..." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 10:34:37 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12100>; Wed, 29 Apr 1992 10:29:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12075>; Wed, 29 Apr 1992 10:24:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 29 Apr 1992 10:20:33 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12059>; Wed, 29 Apr 1992 10:19:44 PDT
Received: by morticia.cnns.unt.edu id AA22109
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Wed, 29 Apr 1992 12:19:14 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001BEF57
In-Reply-to: "<92Apr29.094614pdt.12049@alpha.xerox.com>; from \"Morpheus\" at Apr 30, 92 12:45 am"
Message-ID: <199204291719.AA22109@morticia.cnns.unt.edu>
Date:	Wed, 29 Apr 1992 10:19:13 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	DPMT@uqeve.cc.uq.oz.au (Morpheus)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Further ramblings...

Morpheus (>) writes:
> 
> Finally, Saruman states that other MOO's are "bound to fail" due to the fact
> that new people don't stick to the theme. What I would like to see is a MOO
> where the players have _no_ building/creating commands at all. The emphasis 
> would be on roleplay, not on who can build the cleverest gadget of the month.
> If people don't want to play within a theme, then there is no reason for them
> to continue visiting the MOO.

Funny, isn't this what we've (Jordan, Scott, and I, with others) been working 
on for the past 8 months?  Does no one pay attention here?

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From srvr2.engin.umich.edu!finch.engin.umich.edu!sander Wed Apr 29 10:53:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "10:24:20" "-0700" "Scott D Anderson" "sander@engin.umich.edu" nil "12" "role-playing MOOs" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 10:53:43 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12185>; Wed, 29 Apr 1992 10:45:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12112>; Wed, 29 Apr 1992 10:36:33 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Wed, 29 Apr 1992 10:33:40 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11941>; Wed, 29 Apr 1992 10:28:46 PDT
Received: from srvr2.engin.umich.edu ([141.212.66.64]) by alpha.xerox.com with SMTP id <11908>; Wed, 29 Apr 1992 10:24:30 PDT
Received: from finch.engin.umich.edu by srvr2.engin.umich.edu (5.64/1.35)
	id AA04641; Wed, 29 Apr 92 13:24:27 -0400
Received: by finch.engin.umich.edu (5.64/1.35)
	id 5874d713c.00178df; Wed, 29 Apr 92 13:24:20 -0400
X-NS-Transport-ID: 08002008D0FD001BEF5C
Message-ID: <5874d713c.00178df@finch.engin.umich.edu>
Date:	Wed, 29 Apr 1992 10:24:20 -0700
From:	Scott D Anderson <sander@engin.umich.edu>
Sender: sander%finch.engin.umich.edu@srvr2.engin.umich.edu
To:	moo-cows.PARC@xerox.com
Subject: role-playing MOOs

in reply to morpheus' post - 

there IS a role-playing moo... we are not open yet, but very soon we
will be. this is the godnet. Large emphasis on role-playing, but
with an rpg infrastructure to channel and support the role
playing. players have no building commands, not @create, nothing.

response from the beta-testers has been very encouraging, as well.
i don't think the MOO will fail, either :)

Spetz@lambda
Baal@Godnet

From onet.edu!camp!seth Wed Apr 29 11:07:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "06:15:00" "-0700" "seth%camp@onet.edu" "seth%camp@onet.edu" nil "34" "Re: Further ramblings..." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Wed, 29 Apr 1992 11:07:19 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12067>; Wed, 29 Apr 1992 11:02:57 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12097>; Wed, 29 Apr 1992 10:54:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 29 Apr 1992 10:50:54 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12086>; Wed, 29 Apr 1992 10:40:04 PDT
Received: from suna.osc.edu ([128.146.1.4]) by alpha.xerox.com with SMTP id <11837>; Wed, 29 Apr 1992 10:17:03 PDT
Received: from camp.Onet.EDU ([141.110.32.5]) by suna.osc.edu (5.65c/pl1+KVa/OSC-3.00)
	id AA02745; Wed, 29 Apr 1992 13:16:49 -0400
Received: from campgate.onet.edu by  camp.Onet.EDU (4.1/SMI-4.1)
	id AA13389; Wed, 29 Apr 92 13:16:47 EDT
Received: by campgate.onet.edu with Network-Courier
	id <29FED9A8@campgate.onet.edu>; Wed, 29 Apr 92 13:15:20
X-Mailer: Network Courier V2.1a
Encoding: 34 TEXT
X-NS-Transport-ID: 08002008D0FD001BEF28
Message-ID: <29FED9A8@campgate.onet.edu>
Date:	Wed, 29 Apr 1992 06:15:00 -0700
From:	seth%camp@onet.edu
To:	moo-cows.PARC@xerox.com
Subject: Re: Further ramblings...

Morpheus sez (in part):

> Finally, Saruman states that other MOO's are "bound to fail" due to 
> the fact that new people don't stick to the theme. What I would like 
> to see is a MOO where the players have _no_ building/creating commands 
> at all. The emphasis would be on roleplay, not on who can build the 
> cleverest gadget of the month. If people don't want to play within a 
> theme, then there is no reason for them to continue visiting the MOO.

I don't see that this is the case.  Take, for example, the following
setup (with which I have been toying)

$player     -- with no @create ability
$builder    -- with @create ability
$programmer -- with @create ability and with programming abilities
$wizard     -- with the ability to take any of the other three classes
                 and turn them into edible milk chocolate on a whim.

If all people want to do is roleplay, they can IRC.  The point of designing a 
system in which people can build things is to -let- people build things!  I 
find some of the stuff that people have built to be fascinating.  Yes, 
there's a lot of crap out there, but how much of the crap is just 
unprogrammed objects and how much of it is clever creations?

Theme should be something to take into consideration, but I don't see that 
it's necessarily the be-all and end-all.  I mean REALLY.  No matter HOW big 
this house is, China isn't in the basement.

Again, I am not sure where my ramblings are heading.  So I'll just drop this 
here and look for further comments.  (And I personally prefer MOO-Cows to 
*Theme-Issues, because this is easier for me to sneak in here at work. Heh.)

Blackbriar


From doc.imperial.ac.uk!mjb Wed Apr 29 11:36:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "02:05:22" "-0700" "Matthew Jude Brown" "mjb@doc.imperial.ac.uk" nil "27" "LambdaMOO and Programmer Bits" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 11:36:30 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12006>; Wed, 29 Apr 1992 11:35:37 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12098>; Wed, 29 Apr 1992 11:25:39 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 11:23:12 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12065>; Wed, 29 Apr 1992 11:21:43 PDT
Received: from sun3.nsfnet-relay.ac.uk ([128.86.8.50]) by alpha.xerox.com with SMTP id <11946>; Wed, 29 Apr 1992 11:21:03 PDT
Via: doc.imperial.ac.uk; Wed, 29 Apr 1992 10:01:58 +0100
Via: uk.ac.ic.doc ; 29 Apr 92 10:05 BST
X-Mailer: Mail User's Shell (7.0.3 12/22/89)
X-NS-Transport-ID: 08002008D0FD001BF0BA
Message-ID: <9204291005.aa04079@puffin.doc.ic.ac.uk>
Date:	Wed, 29 Apr 1992 02:05:22 -0700
From:	Matthew Jude Brown <mjb@doc.imperial.ac.uk>
To:	moo-cows.PARC@xerox.com
Subject: LambdaMOO and Programmer Bits

I think the main problem is that Lambda is the only free-access MOO out
there. It would, I think, be unfair and also disadvantageous to the
spread of MOO to make Lambda more restricted. (How else are people to
learn the One True Way ?? :-) Until more MOOs exist I think we're just
going to have to accept something of a lack of theme, else too many
people will be driven away.

I do agree with Morpheus, however, that people should, perhaps, have
spent some time as a player, tried all the player things out, set
messages etc. before going on to the programmer stuff. Perhaps a
probationary time period? Make all but exceptional cases wait a
certain period of time before @programmer? Worth thinking about.

Another part of the problem, as far as I can see, is that there are
a lot of things you need a programmer bit for that are not actually
programming. Many people seem to get a programmer bit just so they
can @chparent to a fancier player class. Perhaps some method could be
introduced whereby such things could be done without full $prog
privileges?

--Morven

-- 
| Matthew J. Brown | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk | Imperial College,  | lectures He wouldn't have created |
| Morven on Lambda | 180 Queen's Gate   | double-sided photocopiers.        |
|__________________| LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

From spock.vax.aston.ac.uk!WHEELERC Wed Apr 29 11:47:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "05:57:00" "-0700" "\"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES.\"" "WHEELERC@spock.vax.aston.ac.uk" nil "45" "To be, or not to be ... a MOO programmer" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 11:47:37 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11908>; Wed, 29 Apr 1992 11:47:05 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11917>; Wed, 29 Apr 1992 11:35:50 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 11:32:05 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12067>; Wed, 29 Apr 1992 11:25:53 PDT
Received: from sun3.nsfnet-relay.ac.uk ([128.86.8.50]) by alpha.xerox.com with SMTP id <12006>; Wed, 29 Apr 1992 11:21:08 PDT
Via: spock.vax.aston.ac.uk; Wed, 29 Apr 1992 14:01:42 +0100
X-NS-Transport-ID: 08002008D0FD001BF0BE
Message-ID: <92Apr29.112108pdt.12006@alpha.xerox.com>
Date:	Wed, 29 Apr 1992 05:57:00 -0700
From:	"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES." <WHEELERC@spock.vax.aston.ac.uk>
To:	MOO-COWS <MOO-COWS@xerox.com>
Subject: To be, or not to be ... a MOO programmer


Hi everyone,

I'd like to enter into this debate with a couple of points. I heard about
LambdaMoo from some friends, and went ape when I saw it, I thought it was
brilliant!!

I own an MSDOS m/c do I ftp'd the MSDOS source down from ParcFTP. I then 
started playing around with the LambdaMoo Programmers manual, and the
LambdaCore user & programmer manuals.

I then got back on the MOO only to find how limited the player was, so 
ok. I sent some mail to Haakon asking for the programmers bit, which I
got. Then I started to learn the LamdaMOO built in Utilities, I mean
$command_utils, $perms_utils etc.

As it happens my final year exam revision has caught up with me and now 
I don't have time during the next couple of months to work on my ideas.

My points ? :

1) Many people may well have had to leave things half-finished, I myself 
   am trying to develop a gallery, where text pictures of rooms can 
   provide portals to different areas of the MOO. ie. a place where other
   players can join thier own areas to the mansion, (if I am able to 
   persuade the wiz's to allow me to connect). This project is on a 
   backburner 'til after my degrees over.

2) The main reason I have enjoyed my time on the MOO has been because of 
   the usefulness of applying my mind into designing the ideas I've had.
   Without a programmers bit I doubt I would be as enthusiastic. 

also 

3) A midway status between player and builder/programmer is not that bad
   an idea, but it will not really be effective since those who aren't 
   programmers will resent the way they cannot do everything.

I hope this can engender some more discussion...


Taltos

PS Players and programmers have a quota of 20 objects, any more and you have
to get a wizards approval.

From rsch.oclc.org!stu Wed Apr 29 12:01:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "11:36:23" "-0700" "Stu Weibel" "stu@rsch.oclc.org " nil "11" "Please Don't Do IT!" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 12:01:40 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12092>; Wed, 29 Apr 1992 12:00:06 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11941>; Wed, 29 Apr 1992 11:50:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 11:48:23 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12061>; Wed, 29 Apr 1992 11:47:26 PDT
Received: from rsch.oclc.org ([132.174.1.2]) by alpha.xerox.com with SMTP id <11837>; Wed, 29 Apr 1992 11:37:30 PDT
Received: from seneca.rsch.oclc.org by rsch.oclc.org (4.1/2.890906)
	id AA27545; Wed, 29 Apr 92 14:34:22 EDT
Return-Path: stu@rsch.oclc.org
Received: by seneca.rsch.oclc.org (4.1/2.890906)
	id AA09567; Wed, 29 Apr 92 14:36:23 EDT
X-NS-Transport-ID: 08002008D0FD001BF118
Message-ID: <9204291836.AA09567@seneca.rsch.oclc.org>
Date:	Wed, 29 Apr 1992 11:36:23 -0700
From:	stu@rsch.oclc.org (Stu Weibel)
To:	moo-cows.PARC@xerox.com
Subject: Please Don't Do IT!

Do not restrict this environment - you will retard the rate of
experimentation and innovation.  If you want order, move to an
RL place with strict zoning!

Perhaps I'm too new here to see that there is a problem, but if there is
one, I sure don't see it.  Is it a problem that some people's conception
of the VR is violated by other's? 

Vive la difference!  ['scuse my French]

Twisted-Pere

From lucid.com!yduj Wed Apr 29 12:14:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "11:54:17" "-0700" "Judy Anderson" "yduj@lucid.com" nil "22" "Further ramblings..." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Wed, 29 Apr 1992 12:14:31 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11837>; Wed, 29 Apr 1992 12:04:33 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12071>; Wed, 29 Apr 1992 12:01:34 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 11:58:23 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12106>; Wed, 29 Apr 1992 11:53:46 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <12086>; Wed, 29 Apr 1992 11:52:09 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA28147g; Wed, 29 Apr 92 11:45:01 PDT
Received: by boston-harbor id AA22646g; Wed, 29 Apr 92 14:54:17 EDT
X-NS-Transport-ID: 08002008D0FD001BF154
In-Reply-to: "seth%camp@onet.edu's message of Wed, 29 Apr 1992 06:15:00 PDT <29FED9A8@campgate.onet.edu>"
Message-ID: <9204291854.AA22646@boston-harbor>
Date:	Wed, 29 Apr 1992 11:54:17 -0700
From:	Judy Anderson <yduj@lucid.com>
To:	seth%camp@onet.edu
cc:	moo-cows.PARC@xerox.com
Subject: Further ramblings...

>Theme should be something to take into consideration, but I don't see that 
>it's necessarily the be-all and end-all.  I mean REALLY.  No matter HOW big 
>this house is, China isn't in the basement.

I suppose I have to defend myself about China.  China was originally
created by Rog as a sort of joke; its floor # on the stairwell really
does correspond to the diameter of the earth, assuming 10 feet per
floor.  It was much later turned into a ghetto by me for non-theme
things, when I had totally given up on trying to maintain the theme
and had redefined my goals as simply getting non-theme things far
away.  My only defense is that of insanity :-)

People frequently don't care about the theme.  And it's a lot of work
to be the Theme Police...

These things then build upon themselves.  We let in nontheme things
because it's too much work not to.  Then people see these nontheme
things, and say, hey, my thing isn't any worse than that! and it
snowballs...  Grandfathering is an evil thing.

Judy Anderson yclept yduJ     yduJ@lucid.com    'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu

From microsoft.com!davidsan Wed Apr 29 14:56:36 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "14:15:38" "-0700" "davidsan@microsoft.com" "davidsan@microsoft.com" nil "23" "RE: Please Don't Do IT!" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 14:56:26 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12164>; Wed, 29 Apr 1992 14:52:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12026>; Wed, 29 Apr 1992 14:33:06 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 14:30:55 -0700
Received: from netmail.microsoft.com ([131.107.1.3]) by alpha.xerox.com with SMTP id <11666>; Wed, 29 Apr 1992 14:30:09 PDT
Received: from microsoft.UUCP by netmail.microsoft.com with UUCP (5.65/25-eef)
	id AA01875; Wed, 29 Apr 92 13:17:53 -0700
X-NS-Transport-ID: 08002008D0FD001BF43E
Message-ID: <9204292017.AA01875@netmail.microsoft.com>
Date:	Wed, 29 Apr 1992 14:15:38 -0700
From:	davidsan@microsoft.com
To:	moo-cows@parc.xerox.com
Subject: RE: Please Don't Do IT!

| Do not restrict this environment - you will retard the rate of
| experimentation and innovation.  If you want order, move to an
| RL place with strict zoning!
Well, to some extent, LambdaMOO has strict zoning, at least in theory.
LambdaMOO _has_ a theme, and all 'official' building is supposed to
fit into that theme.  As yduJ's mail made clear, though, not all building
fits that theme.  The issue here seems to be that people think that
they have some kind of right to have access to LambdaMOO, and some kind
of right to build whatever they want to build.  Which seems a bit odd
to me.

| Perhaps I'm too new here to see that there is a problem, but if there is
| one, I sure don't see it.  Is it a problem that some people's conception
| of the VR is violated by other's? 
A more relevant problem is that there are heaps and heaps of unfinished,
irrelevant junk lying around.  I mean, really.  The db is >40 MB now.
Over 40 million bytes of stuff, much of which is trash of one kind or
another (tiny-scenery, clones of generic objects, etc).

Not sure what my point is.  Maybe just that there _is_ a reason to want
to restrict building.
  Dave/Zippy


From lucid.com!yduj Wed Apr 29 15:15:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "14:52:02" "-0700" "Judy Anderson" "yduj@lucid.com" nil "15" "$player and $prog and suchlike." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Wed, 29 Apr 1992 15:15:04 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12178>; Wed, 29 Apr 1992 15:12:05 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11989>; Wed, 29 Apr 1992 15:06:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 15:04:22 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11951>; Wed, 29 Apr 1992 14:59:54 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <12167>; Wed, 29 Apr 1992 14:49:55 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA28591g; Wed, 29 Apr 92 14:42:45 PDT
Received: by boston-harbor id AA23322g; Wed, 29 Apr 92 17:52:02 EDT
X-NS-Transport-ID: 08002008D0FD001BF48B
In-Reply-to: "seth%camp@onet.edu's message of Tue, 28 Apr 1992 06:06:00 PDT <29FD862E@campgate.onet.edu>"
Message-ID: <9204292152.AA23322@boston-harbor>
Date:	Wed, 29 Apr 1992 14:52:02 -0700
From:	Judy Anderson <yduj@lucid.com>
To:	seth%camp@onet.edu
cc:	moo-cows.parc@xerox.com
Subject: $player and $prog and suchlike.

>For example, and I know this is a heinous 
>example, there are way too many people who want to be Schmoos.

I sent mail to *Schmoo on Lambda asking Quinn and the other schmoos
what they think of the idea of maintaining a Simple-Schmoo as a
nonprogrammer alternative that wouldn't have all the cruft that's on
#5803 and #8855 and all the other hacker-type player classes in
between $prog and Schmoo.  It would be a direct child of the base
player class (which is now #3133).  Give it a special "@become this"
verb.  Just a straw man idea, I'm not sure it's the right thing.  Be
sure to generate some traffic on *Schmoo though (now that I've let it
slip I've been reading it :-)

Judy Anderson yclept yduJ     yduJ@lucid.com    'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu

From ccwf.cc.utexas.edu!malirath Wed Apr 29 16:08:52 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "15:59:26" "-0700" "Robert Fisher" "malirath@ccwf.cc.utexas.edu " nil "23" "Programmer debate & pente" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 16:08:45 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11873>; Wed, 29 Apr 1992 16:06:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11683>; Wed, 29 Apr 1992 16:03:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 16:01:40 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11641>; Wed, 29 Apr 1992 16:01:20 PDT
Received: from doc.cc.utexas.edu ([128.83.135.6]) by alpha.xerox.com with SMTP id <11679>; Wed, 29 Apr 1992 15:59:35 PDT
Received: by doc.cc.utexas.edu (5.61/1.34/CCWF 1.18)
	id AA06811; Wed, 29 Apr 92 17:59:26 -0500
X-NS-Transport-ID: 08002008D0FD001BF671
Message-ID: <9204292259.AA06811@doc.cc.utexas.edu>
Date:	Wed, 29 Apr 1992 15:59:26 -0700
From:	malirath@ccwf.cc.utexas.edu (Robert Fisher)
To:	moo-cows.parc@xerox.com
Subject: Programmer debate & pente


	To tell the truth I was really surprised how easy it was to become
a programmer. And I was prepared to do whatever I needed to to prove I was
worthy.
	Although I would certainly have at least one class between player and
programmer in my own MOO, I don't think that it is necessary for LambdaMOO.
Since the wizards seem to want Lambda to be a place where people can indeed
learn and experiment with MOO, I think it would be better to continue making
it easy to become a programmer, but make it hard to get quota. (Of course,
I haven't had the need to ask for more quota yet, so I don't know how hard
it is.) Anyway, just my $0.02.

	Speaking of being worthy of being a programmer: Has anybody played
the Pente game I created? The bugs in it are minor (mainly that the rules
aren't clear enough). I was going to take some time and get it all polished
up, but the connection between here and LambdaMOO hasn't been real reliable
lately.
	Anyway, If anyone has tried it, please mail me and let me know.

	Virtually,
		===========================================
		Robert Fisher / malirath@ccwf.cc.utexas.edu
		===========================================

From con.berkeley.edu!dougo Wed Apr 29 20:12:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "20:03:02" "-0700" "dougo@con.berkeley.edu" "dougo@con.berkeley.edu" nil "49" "MPIF (was Re: Further ramblings...)" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 29 Apr 1992 20:12:20 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11917>; Wed, 29 Apr 1992 20:10:55 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11886>; Wed, 29 Apr 1992 20:08:52 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 29 Apr 1992 20:05:25 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11896>; Wed, 29 Apr 1992 20:04:53 PDT
Received: from con.Berkeley.EDU ([128.32.138.8]) by alpha.xerox.com with SMTP id <11896>; Wed, 29 Apr 1992 20:04:20 PDT
Received: from localhost by con.Berkeley.EDU (5.65/XCF-1.34)
	id AA19038; Wed, 29 Apr 92 20:03:04 -0700
X-Face: (4D-osoq?}7M3\EgvbWKo<JkN/8h)A`1b^S1[8/OtYE1A61B!AOmH#YD+{HKhr7}
	@8gMv~.tsxTzT"g.oP0dTl!q
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD001BF9A7
In-Reply-to: "Your message of \"Thu, 30 Apr 92 00:45:52 PDT.\"
             <92Apr29.094614pdt.12049@alpha.xerox.com>e$2.8 MIL"
Message-ID: <9204300303.AA19038@con.Berkeley.EDU>
Date:	Wed, 29 Apr 1992 20:03:02 -0700
From:	dougo@con.berkeley.edu
To:	moo-cows.PARC@xerox.com
cc:	MPIF@con.berkeley.edu
Subject: MPIF (was Re: Further ramblings...)

I don't have too much to say at the moment, except I want to point out that
none of the issues that have been brought up on Moo-cows in the past two
days are anything new (anyone remember the BUILDER bit back on TinyMuck?)

 > If anyone is interested in further discussing of this and other theme
 > issues, might I suggest we take it to the *themes mail group 
 > on Lambda?

Might I suggest the MPIF mailing list?  Seeing as it's been quite dead
recently (I blame myself for not having the time to put together some
conversation-starters), and the issues brought up have relevance far beyond
just LambdaMOO or MOOs in general.  The address is MPIF@xcf.berkeley.edu;
please send subscription requests to MPIF-request@xcf.berkeley.edu.  There
is a short advertisement on the refrigerator on LambdaMOO.

As I see it, there are (at least) two extremes: a role-playing-based
mud, with a strictly enforced theme policy, with little or no building or
programming except by a core of Wizards/Tinkers/Elders/Gods; and a
completely open mud where everyone is allowed and encouraged to build and
program whatever they want.  The former can work well, but you have to
decide exactly how strictly you want to enforce the theme: how do you
prevent someone from creating FlashGordon when your world is Middle Earth?
Do you force players to have their names and descriptions okayed by the
Wizards before they are allowed to play?  And how do you prevent people
coming on and talking about homework, or dating, or whatever?  Should you
remove general-purpose 'say' and 'emote' verbs?  The latter extreme is just
as problematic: what do you do if someone tries to create a chess-board with
exit objects for every single possible allowable move?  (Believe it or not,
someone actually did this back on Atlantis...)  In an ideal world this
wouldn't necesalleviate the arily even be a problem, but there are real limits as to how
big the database can get without filling the disk drive, or slowing the
response time, or whatever.

Neither one is intrinsically "better" than the other, though the latter
certainly suits itself better towards "test sites" (which is (I think) what
Lambda started out to be); but it's up to the people who run the mud to
decide how far towards either extreme they want to be.  The current
situation in the world of MOO stems from the fact that Lambda is the only
public MOO out there, so people haven't had the chance to experiment with
different ways of running MOOs.  I look forward to seeing whether Godnet
will succeed, though I'm not too optimistic...

Well, I guess I did have something to say; hopefully this will start some
discussion on the MPIF list.  What to you think?  What are some other
advantages and disadvantages to these two extremes?  How successful or
unsuccessful have previous muds of either type been?

-- DougO aka WhiteRabbit aka owner-MPIF
dougo@xcf.berkeley.edu

From maths.tcd.ie!pmcauley Thu Apr 30 01:32:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "01:14:10" "-0700" "Paul Mc Auley" "pmcauley@maths.tcd.ie" nil "21" "Further Ramblings..." "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Thu, 30 Apr 1992 01:32:51 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11526>; Thu, 30 Apr 1992 01:30:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11524>; Thu, 30 Apr 1992 01:28:36 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 30 Apr 1992 01:15:15 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11522>; Thu, 30 Apr 1992 01:14:57 PDT
Received: from salmon.maths.tcd.ie ([134.226.81.11]) by alpha.xerox.com with SMTP id <11522>; Thu, 30 Apr 1992 01:14:24 PDT
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie  Via SMTP (FibreOptic)
          id aa20261; 30 Apr 92 9:14 BST
Organisation: Dept. of Silly Messages
X-Fortune: Death is God's way of telling you not to be such a wise guy.
X-Smiley: [:|]	robot (or other AI project)
X-NS-Transport-ID: 08002008D0FD001BFC93
Message-ID: <9204300914.aa19560@walton.maths.tcd.ie>
Date:	Thu, 30 Apr 1992 01:14:10 -0700
From:	Paul Mc Auley <pmcauley@maths.tcd.ie>
To:	moo-cows.parc@xerox.com
Subject: Further Ramblings...

In the continuing debate....
 One problem with Moo(s) in general is how restrictive the abilities of
$player actually are.  A lot of objects being written require eval to
operate at anything beyond the most basic of levels.  Also in the case of
@chparent, this problem doesn't just apply to player classes, it is also
highly relevant for room building. A player can only use $room and $exit,
for integration into the house or otherwise, would you not want appropriate
room types? What would be nice would be restricted @makeme (player
@chparent), @makehere (room), @makeway (exit); all of which convert existing
objects to one of a restricted class of objects. Restricting player
flexibilities would vastly reduce the enjoyment contained... but I would
advocate a slightly more stringent check of things like .gender and
.description before handing out .programmer (meanwhile, I would ask people
not to jump down a new player's throat the minute they are created about
@desc, It takes time to compose and type such things.)
		Paul

__________________________.
Paul Mc Auley             |   God is real . . . . . .
--------------------------|
AKA pmcauley@maths.tcd.ie |        . . . . . . . . Unless Declared an Integer.

From morticia.cnns.unt.edu!cluther Thu Apr 30 08:28:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "08:17:30" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "25" "Lambda is Killing Moo" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Thu, 30 Apr 1992 08:28:15 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11588>; Thu, 30 Apr 1992 08:27:06 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11613>; Thu, 30 Apr 1992 08:22:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 30 Apr 1992 08:17:59 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11558>; Thu, 30 Apr 1992 08:17:34 PDT
Received: by morticia.cnns.unt.edu id AA24571
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Thu, 30 Apr 1992 10:17:31 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001BFEC7
Message-ID: <199204301517.AA24571@morticia.cnns.unt.edu>
Date:	Thu, 30 Apr 1992 08:17:30 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Lambda is Killing Moo

I just realized a very good reason why there are not more moos around.

Because Lambda is killing moo.

Lambda is so diorganized, so willy-nilly, so baroque, and so plain ugly in
the common areas at least, that new players who might be thinking about
setting up a mud see Lambda and are driven away out of pure
self-preservation.

*I* think moo is the best there is.  Most of you probably do to.  But Lambda
is probably doing more to hinder the proliferation of moos than help it.

Solutions?

1) Scrap Lambda and build something new, and/or
2) Change moo's name to something else and never mention Lambda in the same
   sentence with the new name.

:removes Devil's Advocate badge.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From bds.bds.com!mg Thu Apr 30 13:24:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "13:16:19" "-0700" "Mike Gallaher" "mg@bds.bds.com" nil "69" "Solving the Worlds Problem" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29582>; Thu, 30 Apr 1992 13:24:29 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11649>; Thu, 30 Apr 1992 13:22:32 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11648>; Thu, 30 Apr 1992 13:20:53 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 30 Apr 1992 13:17:15 -0700
Received: from bds.bds.com ([192.107.237.1]) by alpha.xerox.com with SMTP id <11643>; Thu, 30 Apr 1992 13:16:41 PDT
Received: by bds.bds.com (5.61/1.34)
	id AA12080; Thu, 30 Apr 92 16:16:20 -0400
X-NS-Transport-ID: 08002008D0FD001C069D
In-Reply-to: "Your message of Thu, 30 Apr 1992 08:17:30 PDT"
Message-ID: <CMM-RU.1.0.704664979.mg@bds>
Date:	Thu, 30 Apr 1992 13:16:19 -0700
From:	Mike Gallaher <mg@bds.bds.com>
To:	Clay Luther <cluther@morticia.cnns.unt.edu>
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Solving the Worlds Problem

> I just realized a very good reason why there are not more moos around.
> Because Lambda is killing moo.

Oooh, controversy!  Nothing better to get a discussion going!

The message that started this thread began by offering a solution to
some problem, but no one has yet agreed on what the problem is.
So here's my assessment (which is of course correct :-) ):

Truly, a large problem with LambdaMOO is that it's the only one.
I think the real problem is that it's too big for one moo.

There are too many people trying to derive too many different things
from one moo to ever hope to have all of them agree on how it should
look, or why it exists.  Is it a role-playing game?  An experimentor's
workshop?  A place to hang out?  Pick up dates?

No moo can be all those things, all at once.

You can divide the moo up into different areas.  There are already
areas that are primarily role-playing areas, and so on.  But it's
still really all one world, with the same player classes and capabilities.
If you want to restrict a player's actions to enforce a theme in one part,
you have to restrict it everywhere.

If only each part had its own set of classes, each part could have its
own theme, and its own maintainer(s) to enforce it.

So, I see the solution to all the world's (parse that both ways)
problems as:

Distributed moo!	Certainly not a new idea, just more urgently needed.

I suspect that this is already in the works, somewhere.
I think that, done properly, a distributed moo will resolve many of
the theme disagreements.

One way would be to have each "theme area" (world) runs in its own moo
server.  Each moo is linked into the larger world through portals to
other moos, through which you can step into the moo on the other side.


Lambda would become a well-known "branching point" to other worlds (moos).
It could also serve as an introductory world, a haven for hackers, and
a repository for neat objects that can be exported to other moos.

If you want a different theme, step into the appropriate
moo.  In moos that emphasize a "reality" theme, you might have to go
to the train station to do this (or the transfer-booth station).  In a
more informal one, you could just teleport out, or step through a
door.

If someone builds something out-of-place in one moo, the maintainer
could suggest that it be moved to another moo (or move it for them!).
A portal might be left to go to it, if such a portal is appropriate in that world.
(If done transparently enough, the builder might not even be aware that
their creation had been moved, if they weren't too bright.)

I know that many, if not all, of these things have been at least attempted
before, and may have been done since I last looked.

The problem was that each moo was too isolated, with no easy communication
between them.  There was no easy way to move objects from one moo to
another.  Is there such a way now?

mg




From wvnvaxa.wvnet.edu!UN037475 Fri May  1 00:17:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "21:29:49" "-0700" "\"You'll poke your eye out, kid\"" "UN037475@wvnvaxa.wvnet.edu" nil "7" "InterMoo" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Fri, 1 May 1992 00:17:27 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11583>; Fri, 1 May 1992 00:17:13 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11565>; Fri, 1 May 1992 00:14:55 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 1 May 1992 00:12:00 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11583>; Fri, 1 May 1992 00:11:31 PDT
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12066>; Thu, 30 Apr 1992 21:29:59 PDT
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #041B1) id
 <01GJH7M4LMHS95OG7J@WVNVMS.WVNET.EDU>; Fri, 1 May 1992 00:29:49 EDT
X-VMS-To: IN%"moo-cows.parc@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD001C15AC
Message-ID: <01GJH7M4LMHU95OG7J@WVNVMS.WVNET.EDU>
Date:	Thu, 30 Apr 1992 21:29:49 -0700
From:	"You'll poke your eye out, kid" <UN037475@wvnvaxa.wvnet.edu>
To:	moo-cows.parc@xerox.com
Subject: InterMoo

I like the idea of inter-moo communication and have for some time.  Has anyone
experimented with this, and if so what are the possibilities?  Has anyone
written (in MOO-code) an object-interchanging verb which allows copying of an
object or verb or both betwen MOOs?

Gilmore


From ecsuc.ctstateu.edu!PLUMMERS Fri May  1 04:41:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "1" "May" "1992" "04:36:07" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "20" "MOO" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Fri, 1 May 1992 04:41:25 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11565>; Fri, 1 May 1992 04:41:02 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11603>; Fri, 1 May 1992 04:39:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 1 May 1992 04:35:33 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11603>; Fri, 1 May 1992 04:35:01 PDT
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <11693>; Fri, 1 May 1992 04:34:03 PDT
X-Vmsmail-To: SMTP%"moo-cows.PARC@xerox.com"
X-NS-Transport-ID: 08002008D0FD001C17D3
Message-ID: <920501073607.202122b1@ECSUC.CTSTATEU.EDU>
Date:	Fri, 1 May 1992 04:36:07 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	moo-cows.PARC@xerox.com
Subject: MOO


     I think the thing I *really* like about MOO, is that when it is FTPed
it comes to you blank, allowing for the creation of a "theme".
     I was "wizing" on a MOO for a while, but it failed, and turned into a
lpmud (from what I gather), but I have been trying for some time to get my
own sorce code. Unfortunatly I don't have a BSD Unix.
     If someone out there has/is working on a version of MOO that can run on
one of the following _and_ run a full LambdaCore.
               a) VAX/VMS
               b) anything for a 68000 Motorola chip, I am not too attached to the op system.
               c) a IBM PS/1 (386)

     I am planning something closer to godnet than Lambda, I want to rip out
most of the verbs, and try and make a huge game of Shadowrun, as close to the
real rules as possible.  Whether it fails, is not my worry, it will be fun
while it is going....I think a big game like that would be neat.



                                  Saruman

From ecsuc.ctstateu.edu!PLUMMERS Fri May  1 04:47:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "1" "May" "1992" "04:42:30" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "7" "P.S. I forgot to add...." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Fri, 1 May 1992 04:47:56 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11697>; Fri, 1 May 1992 04:47:24 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11691>; Fri, 1 May 1992 04:46:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 1 May 1992 04:42:03 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11691>; Fri, 1 May 1992 04:41:43 PDT
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <11694>; Fri, 1 May 1992 04:40:24 PDT
X-Vmsmail-To: SMTP%"moo-cows.PARC@xerox.com"
X-NS-Transport-ID: 08002008D0FD001C17DA
Message-ID: <920501074230.202132bf@ECSUC.CTSTATEU.EDU>
Date:	Fri, 1 May 1992 04:42:30 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	moo-cows.PARC@xerox.com
Subject: P.S. I forgot to add....


P.S.

     I forgot to mention that I just want to make the database at home, so 
any sorce code you have doesn't have to be for multi-users.

			Saruman

From spock.vax.aston.ac.uk!WHEELERC Fri May  1 13:18:20 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "06:59:00" "-0700" "\"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES.\"" "WHEELERC@spock.vax.aston.ac.uk" nil "24" "Moving the discussion" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Fri, 1 May 1992 13:18:09 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11792>; Fri, 1 May 1992 13:17:14 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11811>; Fri, 1 May 1992 13:13:48 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 1 May 1992 13:05:47 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11800>; Fri, 1 May 1992 13:05:04 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11795>; Fri, 1 May 1992 13:04:16 PDT
Via: spock.vax.aston.ac.uk; Thu, 30 Apr 1992 15:09:33 +0100
X-NS-Transport-ID: 08002008D0FD001C1F32
Message-ID: <92May1.130416pdt.11795@alpha.xerox.com>
Date:	Thu, 30 Apr 1992 06:59:00 -0700
From:	"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES." <WHEELERC@spock.vax.aston.ac.uk>
To:	MOO-COWS <MOO-COWS@xerox.com>
Subject: Moving the discussion


I've seen a couple of suggestions that we move this discussion, elsewhere,
why?  OK so this mailing list is for the discussion of programming, but I
that is what this discussion is about. To be honest I haven't time to get on 
to Lambda and check out the MOO all the time, but this mailing list is keeping
me in touch.

As to mailing lists on the MOO, I read *schmoo (I'm a schmoo, happy to be 
one, and I did @list on all verbs defined on me before I used them.), but
I dont know of any others. If there are lists of interest could someone mail
me the names of the ones to subscribe to - thanks.

I will look forward to seeing Godnet, as I think it sounds like a great
idea, in its place. I want to program, and I enjoy it. My projects (briefly
mentioned previously) are an attempt to fit in with the house, and yet allow
others to explore other areas of thier imagination.  I like the theme of 
the Lambda-house, but I don't like to see imagination limited. Directed maybe,
but not limited


Thanks for listening


Colin

From spock.vax.aston.ac.uk!WHEELERC Fri May  1 13:25:20 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "1" "May" "1992" "04:02:00" "-0700" "\"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES.\"" "WHEELERC@spock.vax.aston.ac.uk" nil "72" "Colin rambles on ... and on ..." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Fri, 1 May 1992 13:25:10 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11809>; Fri, 1 May 1992 13:24:18 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11800>; Fri, 1 May 1992 13:21:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 1 May 1992 13:14:26 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11797>; Fri, 1 May 1992 13:13:31 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11790>; Fri, 1 May 1992 13:04:46 PDT
Via: spock.vax.aston.ac.uk; Fri, 1 May 1992 12:11:28 +0100
X-NS-Transport-ID: 08002008D0FD001C1F37
Message-ID: <92May1.130446pdt.11790@alpha.xerox.com>
Date:	Fri, 1 May 1992 04:02:00 -0700
From:	"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES." <WHEELERC@spock.vax.aston.ac.uk>
To:	MOO-COWS <MOO-COWS@xerox.com>
Subject: Colin rambles on ... and on ...


What is Lambda supposed to be about? 

If its a 
fun and friendly enviroment, then I think it succeeds. Organisation
could not be held as a strong point, but I think there is a certain amount
of consistancy.

Also a large number of programmers feel a desire to use thier imagination, and
use thier skills to create interesting enviroments.  I cannot see anything 
wrong with this. HOWEVER I do agree with comments made about half completed
work, abandoned by players who no longer participate, is there no way to remove
objects that belong to players who have not logged in over a period of months?
If some active player has a child of any object then they could be advised by
mail to copy the verbs so the offending (call it 'rotting' object) can be 
removed - or recycled.  This 'tat' would surely reduce the database. (As I 

As for the idea of a player calss split, I took the mail messages home to 
re-read them. And I was confused!

As a player you can use already created objects, call verbs defined on the
location, yourself, or on objects you are carrying (as well as verbs defined
heirachially). 

As a Programmer, you can create new objects, $room, $thing, or children of 
other generic objects. You can add verbs, program verbs, add properties, 
define properties ...

As a builder, erm ..., you can create children of certain objects. To make
an object interesting you would have to be able to redefine properties.

I can't see the builder as being very interesting, to really create good
rooms, objects, puzzles, scenarios etc. you would have to be able to add
properties, and the verbs to use these added props. A subset of verbs perhaps?
I don't think that would work. If you've ever used the minimal.db, you will
know that to start off with no verbs are programmed, and only eval is defined.
so you '.pr' _eval_ then use eval to create new verbs properties which will
make creating and extending the database easier. _eval_ is a great tool, you
can test results of operations, help find bugs. but if you give a builder
_eval_ you are saying, 'you are a programmer, but you have to do everything
in a roundabout way'.  If you don't its a case of making it unnecessarily 
difficult to program, and so less popular. People will lose enthusiasm, and
_then_ the MOO might die.

I feel there is a certain lack of understanding, the programmer class could
just as well be called the builder class. In fact the term would be more 
accurate. To reconcile it with fantasy muds, our $player is a pleb, an 
adventurer, $prog is a builder, $wiz a demi-god, and the arch-wiz (the great
huff-enuff Haakon) the god!

If you don't like the way this MOO is set up then, set up one where experienced
$players say to wizards ' ... I'd like to program this object with this verb to
accomplish this ... ' and the wizard could say ' No we already have something
like that here let me show you ...' or ' OK here's your programmer bit, show me
the object when your finished and I'll give you some quota to build some more'

So $players would serve an 'apprenticeship', and only be granted full 
$prog status after completing thier _meisterwerk_.

I cannot see the point in an intermediate state between $player and $prog, but
I could see the point in limiting the promotion of $player. On Lambda I cannot
imagine this being implemented, since to take $prog away from players would be
considered as behaving clique-y and elitist. 

Lets move this discussion more into how we can remove the 'tat' from the MOO,
lose players who no longer use the MOO, and clean up generally. I would be
happy to help, and I'm sure others would too. ( The database is 45000+ obj.)


Colin



From lucid.com!yduj Fri May  1 15:04:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "1" "May" "1992" "15:01:24" "-0700" "Judy Anderson" "yduj@lucid.com" nil "25" "reaping inactives." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Fri, 1 May 1992 15:04:36 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11805>; Fri, 1 May 1992 15:03:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11802>; Fri, 1 May 1992 15:01:31 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 1 May 1992 14:59:40 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11753>; Fri, 1 May 1992 14:59:22 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA03946g; Fri, 1 May 92 14:52:02 PDT
Received: by boston-harbor id AA01290g; Fri, 1 May 92 18:01:24 EDT
X-NS-Transport-ID: 08002008D0FD001C2150
In-Reply-to: "Matthew Jude Brown's message of Thu, 30 Apr 1992 05:46:03 PDT <9204301346.aa06729@puffin.doc.ic.ac.uk>"
Message-ID: <9205012201.AA01290@boston-harbor>
Date:	Fri, 1 May 1992 15:01:24 -0700
From:	Judy Anderson <yduj@lucid.com>
To:	mjb@doc.imperial.ac.uk
cc:	moo-cows@parc.xerox.com
Subject: reaping inactives.

We've been purging folks who have built "nothing interesting" after an
idle period of nine months.

"Nothing interesting" is currently defined as no verbs owned.  Most of
the stuff so junked has also had no description or very boring
descriptions (I spot check the stuff that's automatically discovered
by Dren's Salvage Factory, #546).

Note also that players who don't set descriptions on themselves and
don't own anything get reaped after 2 months whenever I run Nosredna's
find_bozos verb.  Now that we're on registration there are gonna be
lots fewer of these.

Note that Colin was incorrect when he said there were 46000 objects in
the DB.  Objnums aren't reused.

:proselytizes about objnum reuse

Reaped players and their objects don't get recycled, instead they get
stripped of their identity and go into #4455, the toad pile, to be
reused by #5803 descendents who have set their .recreate_enabled
property to 1...  (Say "help recycling" if you're a #5803 :-)

Judy Anderson yclept yduJ     yduJ@lucid.com    'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu

From unipress.com!joe Fri May  1 15:31:50 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "1" "May" "1992" "15:26:40" "-0700" "joe@unipress.com" "joe@unipress.com" nil "58" "Re: $prog and all that" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Fri, 1 May 1992 15:31:39 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11766>; Fri, 1 May 1992 15:31:15 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11757>; Fri, 1 May 1992 15:29:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 1 May 1992 15:27:57 -0700
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <11764>; Fri, 1 May 1992 15:27:27 PDT
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA12708; Fri, 1 May 92 18:27:09 EDT
Received: from dot.UniPress.COM by repo.unipress.com (4.1/SMI-4.1/UniPress121291.1)
	id AA04063; Fri, 1 May 92 18:27:05 EDT via
X-NS-Transport-ID: 08002008D0FD001C21B7
In-Reply-to: "Your message of \"Thu, 30 Apr 92 05:46:03 PDT.\"
             <9204301346.aa06729@puffin.doc.ic.ac.uk>ED"
Message-ID: <9205012227.AA04063@repo.unipress.com>
Date:	Fri, 1 May 1992 15:26:40 -0700
From:	joe@unipress.com
To:	moo-cows@parc.xerox.com
Subject: Re: $prog and all that


This is my $.02.

>From the LambdaMOO times, dated Wed Apr 29, 1992:
> With the larger numbers of players we've been seeing, I'm sure many of you
> have noticed that the server has been hard-pressed to keep up with the demand.
> Please be courteous to the server, and avoid running CPU expensive commands
> frivolously.  Work by Haakon this summer should substantially improve the
> situation, but we have to pull together to survive until then.

For all it's amazing capability, MOO isn't as smart as it possibly could be
with memory management.  Given a better memory management scheme (say,
copy-on-write rather than copy-on-reference strings), who knows what size the
db would shrink to?

There are even other technical methods of solving the problems leading to
"$prog and all that."  One would be a disk based db.  Another (already
mentioned in this discussion) would be a distributed MOO.  These being the
best solutions I can see, and given that I am not willing to implement them,
the only reasonable thing I can do is "pull together" with everybody else with
the server performance as it is, which is not such an unreasonable thing in
the first place.  It may be unreasonable to others using lambda.xerox.com for
things other than MOO, but I can't say what goes on here.

> there are heaps and heaps of unfinished,
> irrelevant junk lying around.  I mean, really.  The db is >40 MB now.
> Over 40 million bytes of stuff, much of which is trash of one kind or
> another (tiny-scenery, clones of generic objects, etc).

The *theory* is that since the MOO is run on a machine with virtual memory,
all the unused stuff will get swapped out to disk.  In actuality, locality of
reference is probably poor in MOO (although I can't say that with any
authority), so the number of pages which tend to stick around in physical
memory (or cause trashing) is probably higher than would be desirable.  This
theory worked sort of OK for 40Mb TinyMUD databases, but I don't think the
philosophy still holds.  Again, this is a technical problem.

A database purge, restricted building, and even new player registration would
all help the performance of the server, but these solutions would also effect
the freedom which Lambda House provides.  I wouldn't be happy about losing my
programmer bit (even though I haven't programmed anything in *quite* a while),
and I'm sure that others would be burnt by the other measures.  Improvements
to MOO, on the other hand, would help performance of the server as well,
perhaps more than policy wrenches, and would not impair the wonderful MOO
freedom which is now available in LambdaMOO.

Nobody should take this as a plea from me for somebody else to improve MOO.  I
hate it when people ask me to fix things for them in this way, and I certainly
don't want to be a hypocrite.  My point is simply that the server performance
is tolerable for me, and I think efforts to improve MOO should be weighed in
along with the database reduction policies in this discussion.

BTW, I believe that inactive player purges have occurred in the past, and I
wouldn't be surprised at future ones.  I'm not arguing against this, just
pointing at some other stuff which I think should be brought into
consideration in this mail thread.

-K* (SHOT FROM GUNS)

From xerox.com!parc.xerox.com.PARC Sun May  3 09:09:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "2" "May" "1992" "15:44:55" "-0700" "Michael Richardson" "mcr@latour.sandelman.ocunix.on.ca " nil "24" "ProgrammersManual" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 3 May 1992 09:09:07 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11880>; Sun, 3 May 1992 09:07:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11876>; Sun, 3 May 1992 09:04:41 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sun, 3 May 1992 09:01:17 -0700
Received: from mail.uunet.ca ([142.77.1.1]) by alpha.xerox.com with SMTP id <11878>; Sun, 3 May 1992 09:00:49 PDT
Received: from ocunix by mail.uunet.ca with UUCP id <10131>; Sun, 3 May 1992 12:00:39 -0400
Received: by micor.OCUnix.On.Ca (smail2.5)
	id AA08526; 2 May 92 19:15:07 EDT (Sat)
Received: by sandelman.ocunix.on.ca id AA05419
  (5.65a/IDA-1.4.2 for moo-cows@parc.xerox.com); Sat, 2 May 92 18:45:05 -0400
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-NS-Transport-ID: 08002008D0FD001C2AB0
Message-ID: <9205022245.AA05419@sandelman.ocunix.on.ca>
Date:	Sat, 2 May 1992 15:44:55 -0700
From:	mcr@latour.sandelman.ocunix.on.ca (Michael Richardson)
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: ProgrammersManual

  I hate to break up the great debate over what LambdaMOO theme's should be.
(If nothing else, this debate made me log back into Lambda after several
months absense and look around trying to find some of the stuff that didn't 
fit in :-) )
  I had ftp'ed MOO 1.5 for home (3/60). I pulled it off disk today and
took a look at the ProgrammersManual. I makeinfo'ed it. To my disappointment,
there were no info nodes at all in the document.
  I once info'ized the 1.1 manual (before Haakon switched to texinfo I think),
and I was hoping that the new manuals would be amenable to info viewers
too (what with mud.el and info-mode, one has a very nice reference to
try out new things)
  I would just like to repeat my plea to include @node lines in there too.
It is just too usefull not to go that extra little bit. 
  Thanks.


-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca     Bell: (613) 237-5629
SCHOOL: 192228@physics.carleton.ca      




From phantom.com!dead Sun May  3 16:33:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "3" "May" "1992" "16:22:00" "-0700" "Bruce Fancher" "dead@phantom.com " nil "16" "" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 3 May 1992 16:32:56 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11895>; Sun, 3 May 1992 16:32:28 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11892>; Sun, 3 May 1992 16:29:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 3 May 1992 16:26:09 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11891>; Sun, 3 May 1992 16:25:47 PDT
Received: from phantom.com ([38.145.218.221]) by alpha.xerox.com with SMTP id <11891>; Sun, 3 May 1992 16:25:04 PDT
Received: by phantom.com (/\==/\ Smail3.1.25.1 #25.5)
	id <m0lhpt5-0003zOC@phantom.com>; Sun, 3 May 92 19:22 EDT
X-NS-Transport-ID: 08002008D0FD001C2C50
Message-ID: <m0lhpt5-0003zOC@phantom.com>
Date:	Sun, 3 May 1992 16:22:00 -0700
From:	dead@phantom.com (Bruce Fancher)
To:	moo-cows.parc@xerox.com

    The real problem as I see it is NOT that Lambda is a mess (which
it is).  If you download the moo source off of Parc and set it up
you're starting with a fresh database file so the chaos on Lambda has
no affect on a new moo.  We all know and love the way Pavel made it so
easy to build and write new commands and objects for moo.  If you want
to modify a diku-mud you need a to edit the database file by hand and
re-write the server code. 
    The real reason people aren't running moos, is because Lambda is
so slow.  It runs on a Sparc, which is a computer I was led to believe
was rather fast, but when 30 people are logged into it, and only 15 or
so are actually doing anything the server slows to a crawl.  On the
other hand I've been logged into Adversary diku-mud at Temple with 55
people and noticed no delays.  No matter how brilliantly concieved and
executed (and it is) moo is no one is going to want to run one until
Pavel or someone writes a compiler for the language or does something
to speed it up.

From phyvs1.anu.edu.au!dxb105 Mon May  4 01:07:08 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "April" "1992" "09:28:47" "-0700" "David Bofinger" "dxb105@phyvs1.anu.edu.au" nil "43" "Programmer Bits" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 4 May 1992 01:07:05 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11526>; Mon, 4 May 1992 01:05:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11527>; Mon, 4 May 1992 01:04:04 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Mon, 4 May 1992 01:00:37 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11525>; Mon, 4 May 1992 01:00:11 PDT
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <11525>; Mon, 4 May 1992 00:59:30 PDT
Received: by phys.anu.edu.au (MX V2.3) id 2089; Thu, 30 Apr 1992 12:28:47 EDT
X-NS-Transport-ID: 08002008D0FD001C2E77
Message-ID: <00959E09.FEAC80A0.2089@phys.anu.edu.au>
Date:	Thu, 30 Apr 1992 09:28:47 -0700
From:	David Bofinger <dxb105@phyvs1.anu.edu.au>
To:	moo-cows.parc@xerox.com
cc:	dxb105@phyvs1.anu.edu.au
Subject: Programmer Bits

>On the GodNet, we originally removed the concept of players having programmer
>bits (aka Lambda) precisely because we didn't want people coming in, making
>buggy junk, and leaving us with a handful of worthless objects and a bloated
>database.

I hope everyone here realises there's a distinction between quota and
programmer bits. The best way to spam your database with worthless objects is
to give everyone quota and nobody programmer bits. I fully agree quota needs to
be restricted somehow, but that's a totally separate question from restricting
programmer bits.

>However, as our opinions mellowed, it became somewhat clear that a good reward
>for players would be having a builder level, where the player gets a programming
>bit.  This would not use the $prog, but rather, just allow the builder player
>to build and program a small collection of objects.  They still would not get
>"magical" abilties like being able to teleport or see and get things from
>afar.

Problem: those "magic" programs don't rely on any special privileges to write.
As MOO stands if you can program you can basically do those things unless the
owner of the room/thing objects. I suppose you could give the crime of
"creating a .free_entry room" the death sentence, that might work.

>Definitely a strongly themed mud/moo, and we have no
>sympathy or empathy for players who can't live within that theme.

One thing that would help, IMNPHO, is an automated theme-enforcer. Something
that kills areas (after several warnings) if an official hasn't OKed them
within <whatever> weeks after {they are built | the quota is allocated}. Takes
the pressure off the architecture review board. Perhaps each object could be
associated with a project, and a project's right to exist expires after a
certain time without approval.

It would also be a help if the quota system could more accurately represent
bloat-load, but again that's a server problem.

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
		MOO:	Maybe G7 again sometime.
------------------------------------------------------------------------------
"To our friends, the good guys. And to our enemies, the bad guys. And to the
hope that someday we will be able to tell the difference." - Keith Laumer

From phyvs1.anu.edu.au!dxb105 Mon May  4 01:14:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "29" "April" "1992" "15:19:06" "-0700" "David Bofinger" "dxb105@phyvs1.anu.edu.au" nil "80" "A voice from the past on .programmer bits" "^Date:" nil nil "4"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 4 May 1992 01:14:36 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11531>; Mon, 4 May 1992 01:13:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11526>; Mon, 4 May 1992 01:11:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Mon, 4 May 1992 01:08:21 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11528>; Mon, 4 May 1992 01:07:52 PDT
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <11530>; Mon, 4 May 1992 01:06:49 PDT
Received: by phys.anu.edu.au (MX V2.3) id 1881; Wed, 29 Apr 1992 18:19:06 EDT
X-NS-Transport-ID: 08002008D0FD001C2E7F
Message-ID: <00959D71.C4E07F40.1881@phys.anu.edu.au>
Date:	Wed, 29 Apr 1992 15:19:06 -0700
From:	David Bofinger <dxb105@phyvs1.anu.edu.au>
To:	moo-cows.parc@xerox.com
cc:	dxb105@phyvs1.anu.edu.au
Subject: A voice from the past on .programmer bits

Morpheus admits to being fooled by wizards:
>The threat of not having rooms linked to the main house seemed to _mean_
>something then.

>Now, prog bits are handed out almost the instant the new player steps out of
>the closet.

I once agitated for instant enprogrammerment, by automatic procedure. It seems
to me that the in-between "we'll give it to you but you have to ask" is a
strange compromise.

>However, there are a large number of players who are
>given these bits when they haven't even fleshed out their characters...
>descriptions and genders are left unset,

Have to cater to the "clueless computer-weenies with no imagination" crowd,
Morpheus. We ned them as allies against the "clueless computer-illiterates with
no imagination" crowd, who handily outnumber everyone else put together.

> several junk items are created, then
>the character disappears, never to be heard from again.

As long as the abandoned character and possessions quickly catch fire and burn
to the waterline, that isn't such a problem. I'm the original proponent of the
"infanticide not contraception" policy, i.e. let people build as they wish and
destroy anything that doesn't conform. And have an automatic enforcer that has
to be actively prevented from destroying things, so that the onus isn't thrust
on the wizards.

> People will be requesting prog bits now just to gain more quota
>(I could be talking through my hat here...I'm assuming that players are
>granted more quota once they've been given programmer status).

I wouldn't approve of such a policy. Quota increases should reward acheivments,
seems to me.

>Growth has practically ceased. In my opinion, a small
>core of programmers with a clear idea of what can be accomplished within theme
>would be infinitely more benefitial than a multitude of people all thrusting
>their chaotic concepts into the house.

Having hordes of morons ambulating about doesn't actually prevent the elite
from building. I wouldn't think it reduced growth, except perhaps because
wizards (who tend to be significant builders) are tied down as administrators.

Strange, this letter was originally intended to contain just that last
paragraph....

Somebody said they tried to build a strong-theme MOO and it crashed because
nobody would follow the theme. All I can suggest is that if you want a theme
you have to be fascist. "Let a thousand flowers blossom" is great for a
hackers' delight like Lambda, but if you want everyone to conform you have to
be prepared to haul out the weedkiller at the slightest provocation. A good
mechanism for this might be the provisional quota increase. One month (or
whatever) after such an increase everything a player owns above eir old limit
is destroyed. A wizard (or perhaps, any member of the architecture review
board) can provide provisional or permanent quota increases or extend
provisional ones as e sees fit.

A starting player has the following quota structure:

 -1 permanently (e has to pay for existing at all...)
  1 object  for 6 months (extended every time e logs in)
 20 objects for 2 months (enough to build a decent starting project)

Of course, if the quota goes negative at any time objects get recycled until it
is zero again. If necessary, until the player object itself dies. You'd need a
few heuristics to decide what order objects get killed in... exits before the
rooms they connect, I guess, and player objects last. Transfer of ownership
after creation may be a minor problem.

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
		MOO:	Nobody much these days....
------------------------------------------------------------------------------
"Eccentricity has always abounded where strength of character has also, and the
 amount of eccentricity in a society has generally been proportional to the
 amount of genius, mental vigour and moral courage which it contained."
					     -- "On Liberty", John Stuart Mill

From morticia.cnns.unt.edu!cluther Mon May  4 08:27:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "4" "May" "1992" "08:20:33" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "21" "Quota in a Themed Moo" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 4 May 1992 08:27:24 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11566>; Mon, 4 May 1992 08:27:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11567>; Mon, 4 May 1992 08:25:13 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Mon, 4 May 1992 08:21:30 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11547>; Mon, 4 May 1992 08:20:56 PDT
Received: by morticia.cnns.unt.edu id AA03363
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Mon, 4 May 1992 10:20:35 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C32C7
Message-ID: <199205041520.AA03363@morticia.cnns.unt.edu>
Date:	Mon, 4 May 1992 08:20:33 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Quota in a Themed Moo

In the GodNet, we are linking building quota directly to player's experience
(though we do not use a standard hokey rpg experience or level method).

The currency of the GodNet is Pleasure, with its consumer, Desire.  Any time
the player wishes to create or purchase anything, he must give up Pleasure,
which weakens him (and makes him more susceptible to Desire). 

We are linking a player's building quota to his Pleasure, and, indirectly, his
Faith.  Thus, only players with significant Faiths (either pro- or anti- 
CyberPapacy) will gain the ability to build, and then they are restricted in 
their building by how much Pleasure they can spend.  And since losing/gaining
Pleasure will sometimes increase Desire (depending no the amount gained/lost),
players will have a built-in influence to keep their building succinct and
useful.


-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From xerox.com!parc.xerox.com.PARC Tue May  5 07:54:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "5" "May" "1992" "07:28:42" "-0700" "Thomas Kunselman" "tek@ms.uky.edu" "<9205051428.aa28136@s.s.ms.uky.edu>" "42" "Quotas" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 5 May 1992 07:53:53 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11758>; Tue, 5 May 1992 07:51:13 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11761>; Tue, 5 May 1992 07:48:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Tue, 5 May 1992 07:43:24 -0700
Received: from mozart.ms.uky.edu ([128.163.128.127]) by alpha.xerox.com with SMTP id <11758>; Tue, 5 May 1992 07:42:50 PDT
Received: from s.ms.uky.edu by mozart.ms.uky.edu id aa16329; 5 May 92 10:30 EDT
X-NS-Transport-ID: 08002008D0FD001C43DE
Message-ID: <9205051428.aa28136@s.s.ms.uky.edu>
Date:	Tue, 5 May 1992 07:28:42 -0700
From:	Thomas Kunselman <tek@ms.uky.edu>
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: Quotas

Aren't quotas interesting?  limited resources is one of the things that
make muds  in general most life-like.

I think it is a good idea to start everyone off with a certain quota, and
then have some way to increase quotas for 'good' builders/creators.  And
how do you determine what is 'good'?  Why not let the market decide?

Would it be possible to base quota increases on useage?  If someone builds
a neat room that people like to hang out in, why not give them so much
extra quota per so many units of use?  That way, the person will have the
quota to build more rooms that people might like to hang out in.

If someone programs a neato object, then why not give them increased quota
based on how many people carry around the object or how many people clone/
child an object off the generic? That way the good programmer has more
quota to build more objects.

Use would have to have a couple of different definitions to reward the
different types of creation availble, from building to programming, to
just plain old artistic description of objects of art that people carry
around cause they are pretty.

You could still establish a maximum quota for individuals, as well as a
maximum quota  of uncreated objects.  So say, someone is very popular,
yet even though their objects receive much useage, they still don't receive
more than 30 or 50 increased quota, cause 50 unbuilt objects may be a limit.

Or maybe you would want to limit the number of new objects per day, so
at the end of the day or week, when quota's would be recalculated, they
would receive the % of total quota awarded based on the % of total useage
they had acquired.

Wow, then wouldn't it be neat if people could spend their unused quota like
money? :-)

 
--
Thomas Kunselman                              {rutgers,uunet}!ukma!tek          
Institutional Research and Planning       	bitnet: vaatek@ukcc.bitnet
#7 Administration Building			internet:tek@ms.uky.edu
University of Kentucky
Lexington, KY 40506-0032			(Educate, Don't Legislate!)

From parc.xerox.com!pavel Tue May  5 13:37:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "5" "May" "1992" "13:28:25" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "6" "Re: Quotas" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 5 May 1992 13:37:52 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11780>; Tue, 5 May 1992 13:36:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11767>; Tue, 5 May 1992 13:32:33 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Tue, 5 May 1992 13:29:11 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11730>; Tue, 5 May 1992 13:28:51 PDT
Received: by lambda.parc.xerox.com id <58378>; Tue, 5 May 1992 13:28:40 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001C49DE
In-Reply-to: <9205051428.aa28136@s.s.ms.uky.edu>
Message-ID: <92May5.132840pdt.58378@lambda.parc.xerox.com>
References: <9205051428.aa28136@s.s.ms.uky.edu>
Date:	Tue, 5 May 1992 13:28:25 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	tek@ms.uky.edu, moo-cows@parc.xerox.com
Subject: Re: Quotas

Tek's notion of quota-as-currency is reasonably close to the economy planned
for MOOniversal Studios, expected to go on line in the fall, but saying any
more might spoil the surprise...

	Pavel/Haakon the Enigmatic
	:-)

From spock.vax.aston.ac.uk!WHEELERC Wed May  6 05:45:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "02:00:00" "-0700" "\"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES.\"" "WHEELERC@spock.vax.aston.ac.uk" "<92May6.053257pdt.11894@alpha.xerox.com>" "13" "give me some SPEED man!!" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 05:45:09 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11981>; Wed, 6 May 1992 05:44:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11975>; Wed, 6 May 1992 05:41:21 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58379>; Wed, 6 May 1992 05:34:11 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11966>; Wed, 6 May 1992 05:33:45 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11894>; Wed, 6 May 1992 05:32:57 PDT
Via: spock.vax.aston.ac.uk; Wed, 6 May 1992 09:59:25 +0100
X-NS-Transport-ID: 08002008D0FD001C5375
Message-ID: <92May6.053257pdt.11894@alpha.xerox.com>
Date:	Wed, 6 May 1992 02:00:00 -0700
From:	"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES." <WHEELERC@spock.vax.aston.ac.uk>
To:	MOO-COWS <MOO-COWS@xerox.com>
Subject: give me some SPEED man!!


I should think everyone has seen the message in the News bulletin,
that runs along the lines of server is slow due to heavy use ... work by
Haakon over the summer will improve this.

What is Haakon planning on doing, and could anyone spill the beans on why
the load makes it so slow.  If someone where to set up another MOO, how
would the avoid Mundo-Lag ( ... Dudes ?)


Colin



From parc.xerox.com!pavel Wed May  6 10:35:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "10:22:33" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "118" "Re: give me some SPEED man!!" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 10:35:38 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11880>; Wed, 6 May 1992 10:35:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11893>; Wed, 6 May 1992 10:28:41 PDT
Received: by lambda.parc.xerox.com id <58371>; Wed, 6 May 1992 10:22:42 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001C5876
In-Reply-to: <92May6.053257pdt.11894@alpha.xerox.com>
Message-ID: <92May6.102242pdt.58371@lambda.parc.xerox.com>
References: <92May6.053257pdt.11894@alpha.xerox.com>
Date:	Wed, 6 May 1992 10:22:33 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Re: give me some SPEED man!!

   What is Haakon planning on doing, and could anyone spill the beans on why
   the load makes it so slow.

There are three major reasons for the lag on LambdaMOO:

1) The server currently does an enormous amount of value-copying, to allow it
   to safely and easily free up storage when it's no longer needed.  The idea
   is that every part of the code makes its own copies of the values it uses,
   so every part can feel free to dispose of its copy when its own, local needs
   are satisfied.

   The solution to this problem is at the top of my agenda for when I get back
   to doing major server hacking this summer.  I will begin using
   reference-counting to determine when it's safe to free values.  This will
   almost entirely eliminate the copying of values.  Since the server currently
   spends a major fraction of its time (around 60% on average, as I recall, and
   much much more in certain nasty cases), this change should have a
   significant impact on server performance.

2) The entire LambdaMOO database is maintained in memory on the server.  For
   LambdaMOO currently, this means about 85 megabytes of virtual memory.  The
   machine on which LambdaMOO runs has only 64 megabytes of physical memory, so
   there is the potential for major thrashing, moving pages from memory to disk
   and back again.  As it turns out, however, this is not a significant problem
   in normal use.  It becomes a major problem only when the server is making a
   checkpoint of the database into a disk file.  To do this, the server process
   clones itself (`forks', in UNIX parlance) so that one clone can write out a
   consistent copy of the DB to disk while the other continues to provide
   service to the users.  Of course, when the server is already using 85
   megabytes and it clones itself, it begins using 170 megabytes; further, one
   of those clones is systematically running through essentially *all* of that
   memory, copying it to disk.  This leads to an incredible amount of thrashing
   and, thus, to incredible lag.

   The solution to this problem is second on my agenda for the summer.  I will
   be making the major changes necessary to move the primary storage of the DB
   from memory to disk, more along the lines of a standard database
   implementation.  This will eliminate the need for checkpointing at all
   (since the DB will already be on disk) and vastly decrease the memory
   requirements of the server (since memory would only be used as a cache of
   disk contents).  This major source of lag will be completely eliminated.  As
   a pleasant side-effect of this change, it will become much more reasonable
   for people to run the LambdaMOO server on small machines, notably PC's.

3) The current LambdaMOO task scheduler is not well-suited to the typical mix
   of forked vs. command tasks.  In particular, it is forced by the current
   specification of the language to give background tasks five seconds or
   30,000 ticks of runtime before aborting them.  That is five seconds during
   which the server must ignore command tasks.  Further, the scheduler is not
   uniformly giving highest priority to command tasks.  In brief, the scheduler
   lacks sufficient flexibility to do a good job.

   The solution to this problem is at least third on my agenda.  I say `at
   least' because it may be that the reference-counting fix for (1) above will
   significantly ameliorate this problem.  With that fix, I am predicting that
   the vast majority of tasks will very quickly run out of ticks, well before
   they could run out of seconds.  Thus, background tasks will hold up the
   scheduler for much smaller amounts of time, so command response will be that
   much better.

   The fix for this problem lies in a cute idea I had that builds on the
   solution to (2) above.  One aspect of the disk-basing implementation is that
   the server will maintain a list of all DB changes that need to be written to
   the disk.  Embedded in that list are markers, pointing out where the
   boundaries between tasks were.  The server must make sure that the state of
   the disk at any given time reflects exactly the state at some inter-task
   boundary; otherwise, if the server or server machine were to crash, the disk
   copy could be left in an inconsistent state.  Call these task-boundary
   markers `commit points'.  In the new system, the built-in function
   `suspend()', if given an argument of 0, would not necessarily suspend the
   task.  Rather, the server would, at its discretion, do one of three things:
     (a) It might do what's currently done; that is, it might save a copy of
	 the task's control stack on a task queue, insert a commit point
	 into the DB log, and let the next scheduled task begin running.
     (b) It might make the copy of the stack and insert the commit point, but
	 let this task continue running rather than moving to another one.
     (c) It might do nothing at all.
   The idea is that suspend(0) would become just a hint to the scheduler that
   this would be an acceptable place to interrupt the task.  If the suspend(0)
   is in the inner loop of the task, being executed many times, the server will
   almost always ignore it, taking option (c) above.  At strategically-chosen
   times, it would instead take option (b).  Finally, when the scheduler
   decided that this task had run for as long as it was advisable to let it
   run, it would either take option (a) the next time suspend(0) was called or
   else simply stop running the task, effectively backing up in time to the
   last commit point.  It would be as if the scheduler had taken option (a) at
   that time.

   I realize that this is all pretty complicated and difficult to grasp, but
   the programmer's view is simple: suspend(0) will mean either nothing or what
   it currently does and, further, suspend(0) is such a cheap operation that
   you can feel free to insert it in every inner loop of your code.  You would
   no longer have to test ticks_left() or seconds_left() (indeed, they may well
   disappear), but instead you'd do the suspend(0) unconditionally.  The
   scheduler would be free to employ standard, proven operating system
   algorithms to provide good interactive response time and reasonable
   background-task throughput.

   There are more details to be worked out in this fix, but this is enough to
   give you an idea of where I'm headed.

I expect all of these fixes to be released by the end of this summer, almost
certainly along with many other improvements to the server and the MOO
programming language.  In particular, I will release a new version of the
server right after fix (1) is working and again right after fix (2) is done, so
both users of LambdaMOO itself as well as the operators of other MOOs should
see performance improvements as soon as possible.

I hope that this message serves to bolster the community's resolve in toughing
out the current lag problems.  Help *is* on the way; I have not abandoned you
and I'm not deaf to your complaints.

	Pavel/Haakon

PS to Clay Luther: I believe that fix (1) will entirely obviate the need for
your new built-in functions listassoc() and listiassoc(); I'm pretty sure that
the whole reason for the slowness is value copying.  This is especially true of
certain large a-lists, like $player.messages...

From wvnvaxa.wvnet.edu!UN037475 Wed May  6 12:45:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "12:35:57" "-0700" "\"Mr. Rogers works hand-in-hand with the KGB\"" "UN037475@wvnvaxa.wvnet.edu" nil "12" "The New Server of Doom" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 12:45:42 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12011>; Wed, 6 May 1992 12:45:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12007>; Wed, 6 May 1992 12:41:50 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58380>; Wed, 6 May 1992 12:38:23 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12010>; Wed, 6 May 1992 12:38:04 PDT
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <11967>; Wed, 6 May 1992 12:37:36 PDT
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #041B1) id
 <01GJP2OE20PC8WWU3H@WVNVMS.WVNET.EDU>; Wed, 6 May 1992 15:35:57 EDT
X-VMS-To: IN%"MOO-Cows.parc@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD001C5B3C
Message-ID: <01GJP2OE20PE8WWU3H@WVNVMS.WVNET.EDU>
Date:	Wed, 6 May 1992 12:35:57 -0700
From:	"Mr. Rogers works hand-in-hand with the KGB" <UN037475@wvnvaxa.wvnet.edu>
To:	MOO-Cows.parc@xerox.com
Subject: The New Server of Doom

The new server which Pavel plans sounds like a heaven-sent gift; however, he
mentions changes to the MOO prog'ing language.  Will old MOO-code and database
info be completely upward-compatible with the new server?  This is of some
importance to me, as the MOO on which I work is planning to upgrade to the new
server version when it becomes available.

Also, speaking of Clay Luther's modded server, I wonder if the new Pavel server
is going to include Clay's mega-handy regexp() function.


- Gilmore


From csn.org!gregj Wed May  6 13:34:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "13:26:03" "-0700" "Greg Grubbs" "gregj@csn.org" nil "10" "The New Server of Doom" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 13:34:20 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12026>; Wed, 6 May 1992 13:33:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12017>; Wed, 6 May 1992 13:31:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58381>; Wed, 6 May 1992 13:27:02 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12007>; Wed, 6 May 1992 13:26:35 PDT
Received: from teal.csn.org ([128.138.213.22]) by alpha.xerox.com with SMTP id <12003>; Wed, 6 May 1992 13:26:04 PDT
Received: by teal.csn.org id AA02654
  (5.65c/IDA-1.4.4 for MOO-Cows.parc@xerox.com); Wed, 6 May 1992 14:26:03 -0600
X-NS-Transport-ID: 08002008D0FD001C5C14
Message-ID: <199205062026.AA02654@teal.csn.org>
Date:	Wed, 6 May 1992 13:26:03 -0700
From:	Greg Grubbs <gregj@csn.org>
To:	MOO-Cows.parc@xerox.com
Subject: The New Server of Doom

Pavel,

Will it be a fairly simple matter to hack in an alternate database
into the MOO server?  I would very much like to use my company's
database (UniData) for an experimental private MOO.  If your database
read and write calls are done in just a few places, this should be a
simple matter for me.  If not... I won't even try.

Gershwaine/Gregory


From morticia.cnns.unt.edu!cluther Wed May  6 14:44:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "14:35:21" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "21" "Re: The New Server of Doom" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 14:44:06 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12059>; Wed, 6 May 1992 14:43:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12064>; Wed, 6 May 1992 14:42:04 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58383>; Wed, 6 May 1992 14:36:13 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12041>; Wed, 6 May 1992 14:35:49 PDT
Received: by morticia.cnns.unt.edu id AA09235
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Wed, 6 May 1992 16:35:22 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C5DA3
In-Reply-to: "<01GJP2OE20PE8WWU3H@WVNVMS.WVNET.EDU>; from \"Mr. Rogers works hand-in-hand with the KGB\" at May 6, 92 12:35 pm"
Message-ID: <199205062135.AA09235@morticia.cnns.unt.edu>
Date:	Wed, 6 May 1992 14:35:21 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: The New Server of Doom

Mr. Rogers works hand-in-hand with the KGB (>) writes:
> 
> The new server which Pavel plans sounds like a heaven-sent gift; however, he
> mentions changes to the MOO prog'ing language.  Will old MOO-code and database
> info be completely upward-compatible with the new server?  This is of some
> importance to me, as the MOO on which I work is planning to upgrade to the new
> server version when it becomes available.
> 
> Also, speaking of Clay Luther's modded server, I wonder if the new Pavel server
> is going to include Clay's mega-handy regexp() function.

I would hope Pavel will include the regular expression functions to the server.
These are *awfully* useful (of course ;)).  

Besides, I'd hate to have to hack on the new server (again).

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From morticia.cnns.unt.edu!cluther Wed May  6 15:25:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "15:17:10" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "36" "Re: give me some SPEED man!!" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 15:25:21 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12078>; Wed, 6 May 1992 15:24:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12077>; Wed, 6 May 1992 15:22:13 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58384>; Wed, 6 May 1992 15:17:45 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12069>; Wed, 6 May 1992 15:17:13 PDT
Received: by morticia.cnns.unt.edu id AA09354
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Wed, 6 May 1992 17:17:11 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C5E8B
In-Reply-to: "<92May6.102242pdt.58371@lambda.parc.xerox.com>; from \"Pavel Curtis\" at May 6, 92 10:22 am"
Message-ID: <199205062217.AA09354@morticia.cnns.unt.edu>
Date:	Wed, 6 May 1992 15:17:10 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: give me some SPEED man!!

Pavel Curtis (>) writes:
> PS to Clay Luther: I believe that fix (1) will entirely obviate the need for
> your new built-in functions listassoc() and listiassoc(); I'm pretty sure that
> the whole reason for the slowness is value copying.  This is especially true of
> certain large a-lists, like $player.messages...
> 

Kudos.  Of course, I wouldn't complain if the new mods increased the speed so
much that the need for listassoc/listiassoc was obliviated.  That would be
wonderful, indicating an overall enhancement in the server that listassoc/
listiassoc only barely resolve.

However, I cannot state strongly enough the value of the regexp/regsub functions
that we added to the server.  These are almost too useful to ignore.

Although one could make an argument that regexp/regsub could be implemented in
moo, assuming the server speed increases manifold, I would counter that the
implementation currently residing in the modded server is 1) stable, 2) fast,
and 3) already in there (like ragu).  Why waste it and time trying to
reimplement the services at a higher level in the server.  Besides, regexp/
regsub will benefit everyone using the moo server, not just those who choose to
run a lambda-derived db.

And with my programmers clamoring everyday for me to add this or that mod (now
that they know I don't mind dipping my fingers into those muddy waters), who
knows what really interesting and useful mods we can come up with ;).

So, go go Pavel.  But keep your ear to the ground, all the same.



-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From parc.xerox.com!pavel Wed May  6 16:10:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "16:01:57" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "19" "Re: The New Server of Doom" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 16:10:28 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12099>; Wed, 6 May 1992 16:09:02 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12090>; Wed, 6 May 1992 16:07:17 PDT
Received: by lambda.parc.xerox.com id <58385>; Wed, 6 May 1992 16:02:12 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001C5F5D
In-Reply-to: <01GJP2OE20PE8WWU3H@WVNVMS.WVNET.EDU>
Message-ID: <92May6.160212pdt.58385@lambda.parc.xerox.com>
References: <01GJP2OE20PE8WWU3H@WVNVMS.WVNET.EDU>
Date:	Wed, 6 May 1992 16:01:57 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Re: The New Server of Doom

   Will old MOO-code and database info be completely upward-compatible with the
   new server?

Yes.  You may assume this for all future changes unless I specifically say
otherwise.  If I change the database format or make incompatible changes to the
language, I will also provide a reasonable upgrade path for other MOOs.

   Also, speaking of Clay Luther's modded server, I wonder if the new Pavel
   server is going to include Clay's mega-handy regexp() function.

This is very likely, though I don't know how high up it'll be on my priority
list.  It's not very hard to integrate the changes, though, so it'll probably
be pretty early in the next big raft of changes.  I don't guarantee, though,
that the new facilities will be exactly like the ones Clay made available; I
haven't looked at them very closely yet.  If I see what seems to me a better
way of making the same or more functionality available, then I'll probably do
that instead.

	Pavel

From parc.xerox.com!pavel Wed May  6 16:57:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "16:33:40" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "13" "Re: The New Server of Doom" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 16:57:17 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12105>; Wed, 6 May 1992 16:56:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12103>; Wed, 6 May 1992 16:53:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 6 May 1992 16:48:48 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12103>; Wed, 6 May 1992 16:48:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12095>; Wed, 6 May 1992 16:33:51 PDT
Received: by lambda.parc.xerox.com id <58372>; Wed, 6 May 1992 16:33:46 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001C5FC8
In-Reply-to: <199205062026.AA02654@teal.csn.org>
Message-ID: <92May6.163346pdt.58372@lambda.parc.xerox.com>
References: <199205062026.AA02654@teal.csn.org>
Date:	Wed, 6 May 1992 16:33:40 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	gregj@csn.org
cc:	MOO-Cows.parc@xerox.com
Subject: Re: The New Server of Doom

   Will it be a fairly simple matter to hack in an alternate database
   into the MOO server?  I would very much like to use my company's
   database (UniData) for an experimental private MOO.  If your database
   read and write calls are done in just a few places, this should be a
   simple matter for me.  If not... I won't even try.

At the moment, the server checkpoints the database in a very idiomatic fashion
and it would *not* be an easy matter to swap in another DB implementation.  In
the new, disk-based server, I could imagine trying to make this easy.  Is there
an industry standard interface for databases?  If so, then I could try to
follow that interface in my code.  If not, what do you suggest I do?

	Pavel

From lucid.com!yduj Wed May  6 20:50:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "20:46:39" "-0700" "Judy Anderson" "yduj@lucid.com" "<9205070346.AA07654@boston-harbor>" "12" "give me some SPEED man!!" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 20:50:53 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12021>; Wed, 6 May 1992 20:50:40 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12094>; Wed, 6 May 1992 20:48:33 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Wed, 6 May 1992 20:45:14 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11972>; Wed, 6 May 1992 20:44:59 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11989>; Wed, 6 May 1992 20:44:26 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA17112g; Wed, 6 May 92 20:37:05 PDT
Received: by boston-harbor id AA07654g; Wed, 6 May 92 23:46:39 EDT
X-NS-Transport-ID: 08002008D0FD001C62B1
In-Reply-to: "Pavel Curtis's message of Wed, 6 May 1992 10:22:33 PDT <92May6.102242pdt.58371@lambda.parc.xerox.com>"
Message-ID: <9205070346.AA07654@boston-harbor>
Date:	Wed, 6 May 1992 20:46:39 -0700
From:	Judy Anderson <yduj@lucid.com>
To:	MOO-Cows.parc@xerox.com
Subject: give me some SPEED man!!

   You would
   no longer have to test ticks_left() or seconds_left() (indeed, they may well
   disappear), but instead you'd do the suspend(0) unconditionally.  

I would be unhappy if ticks_left(), or some other way of computing
actual ticks used by a process, were to go away.  We really don't have
any other methods of tuning programs.  Yes, I realize that ticks don't
really mean much, but they're all we have...

Judy Anderson yclept yduJ     yduJ@lucid.com    'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu


From parc.xerox.com!pavel Thu May  7 08:26:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "08:15:03" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "7" "Re: give me some SPEED man!!" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 08:25:59 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11590>; Thu, 7 May 1992 08:24:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11580>; Thu, 7 May 1992 08:21:12 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Thu, 7 May 1992 08:16:46 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11596>; Thu, 7 May 1992 08:16:20 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11608>; Thu, 7 May 1992 08:15:40 PDT
Received: by lambda.parc.xerox.com id <58374>; Thu, 7 May 1992 08:15:21 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001C67E5
In-Reply-to: <9205070346.AA07654@boston-harbor>
Message-ID: <92May7.081521pdt.58374@lambda.parc.xerox.com>
References: <9205070346.AA07654@boston-harbor>
	<92May6.102242pdt.58371@lambda.parc.xerox.com>
Date:	Thu, 7 May 1992 08:15:03 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	yduj@lucid.com
cc:	MOO-Cows.parc@xerox.com
Subject: Re: give me some SPEED man!!

   I would be unhappy if ticks_left(), or some other way of computing
   actual ticks used by a process, were to go away.  We really don't have
   any other methods of tuning programs.

Good point.  I had forgotten about their usefulness in performance measurement.

	Pavel

From gestalt.austin.tx.us!garnett Thu May  7 13:35:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "11:52:57" "-0700" "John Garnett" "garnett@gestalt.austin.tx.us" nil "226" "CyberTex" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 13:35:52 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11663>; Thu, 7 May 1992 13:35:03 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11673>; Thu, 7 May 1992 13:30:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Thu, 7 May 1992 13:23:49 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11663>; Thu, 7 May 1992 13:23:12 PDT
Received: from cs.utexas.edu ([128.83.139.9]) by alpha.xerox.com with SMTP id <11663>; Thu, 7 May 1992 13:22:10 PDT
Received: by cs.utexas.edu (5.64/1.128) with UUCP
	id AA11006; Thu, 7 May 92 14:27:53 -0500
Received: from gestalt.austin.tx.us by gestalt.austin.tx.us (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.1)
	id AB05430; Thu, 7 May 92 13:53:25 CDT
X-NS-Transport-ID: 08002008D0FD001C6CF8
Message-ID: <9205071853.AB05430@gestalt.austin.tx.us>
Date:	Thu, 7 May 1992 11:52:57 -0700
From:	John Garnett <garnett@gestalt.austin.tx.us>
To:	MOO-Cows.parc@xerox.com
Apparently-To: mit.edu!erikkay
Apparently-To: mcs.anl.gov!mevard
Apparently-To: cs.uoregon.edu!remy
Apparently-To: cd.chalmers.se!lars
Apparently-To: pegasus.com!huy
Apparently-To: mcshh.hanse.de!amylaar
Apparently-To: fwi.uva.nl!stolk
Apparently-To: anlvm.ctd.anl.gov!U42302%UICVM.BITNET
Apparently-To: cc.brynmawr.edu!t_cornes
Apparently-To: doc.cc.utexas.edu!slwang
Apparently-To: um.cc.umich.edu!psyche
Apparently-To: apathy.NMSU.Edu!spirit
Apparently-To: elof.iit.edu!illya
Apparently-To: cats.ucsc.edu!beeman
Apparently-To: hebrew.cc.columbia.edu!jlw
Apparently-To: vaxb.acs.unt.edu!otto
Apparently-To: xerox.com!MOO-Cows
Apparently-To: iastate.edu!mind
Apparently-To: dining.umd.edu!dreamshadow-staff
Apparently-To: waterloo.austin.ibm.com!crow
Apparently-To: tamuts.tamu.edu!n151dq
Apparently-To: zeus.tamu.edu!RLM7337
Apparently-To: iscsvax.uni.edu!FINLEY0768
Apparently-To: cs.utexas.edu!lhmaddox
Apparently-To: ellis.uchicago.edu!mrh3
Apparently-To: sloth.nmsu.edu!pio
Apparently-To: dante.nmsu.edu!jfreeman
Apparently-To: ub.cc.umich.edu!sara_bez
Apparently-To: nextnet.ccs.csus.edu!johnsond
Apparently-To: ixcim.att.com!rruff
Apparently-To: INDINPLS.NAVY.MIL!724FAB
Apparently-To: INDINPLS.NAVY.MIL!7240fitz
Apparently-To: venus.tamu.edu!cmb0414
Subject: CyberTex

------- Blind-Carbon-Copy

To: fontenot@ravl.rice.edu
Subject: CyberTex
Date: Thu, 07 May 92 13:52:57 -0500
From: John Garnett <garnett@gestalt.austin.tx.us>


hello mudders and cyberspace afficionados,

This note is a compilation of notes regarding mud and cyberspace
and meeting people involved therein.  In April or May of 1993
(I know, forever-away in student time) there will be a CyberTex
conference in Austin, TX (USA).  CyberTex is being organized by
the Austin Chapter of the EFF.  The following notes (almost) explain
what CyberTex is.  At about the same time as the CyberTex conference,
Austin will also be hosting (according to a fairly reliable rumor) the
3rd (4th?) annual Cyberspace conference (this is pretty big, the last few
cyberspace conferences have drawn participation from around the world.
The first Cyberspace conference spawned a book entitled _Cyberspace:
First Steps_ edited by Michael Benedikt).  There is a possibility
these two conferences will ending up nesting in some fashion.

Anyway, there has been some talking of making Mud a part of the
CyberTex conference.  Perhaps have demoes of muds and provide
a place and time for people who are involved in mudding to meet
(so you can meet all of those people you know but don't know :).

So... read the following notes and let me know what you think.
I think it would be a great opportunity for everyone to meet and
play and maybe even demo what they have been "working" on.

I'm interested in receiving ideas from anybody on what the mud
community could/should/might do in conjunction with CyberTex
and the Cyberspace conference.

- --John

p.s. pass this note on to whomever you like.  also, let me know if you'd
be interested in being on a mailing list formed to discuss having a mudder
(demos, BOF, etc) gathering at the CyberTex and Cyberspace conferences.
if there's enough interest, i'll set up such a list.

- -- cut here --

- ------- Forwarded Message

Date: Sat, 25 Apr 92 23:06:48 -0500
From: jonl@tic.com (Jon Lebkowsky)
Message-Id: <9204260406.AA05028@aahsa.tic.com>
To: cybertex@tic.com, eff-a@tic.com
Subject: CyberTex wants *you*!

                            CALL FOR VOLUNTEERS!
 
CyberTex (Virtual Rodeo) is actively organizing. Target date for the
conference is April 1993...we need to begin work right away to meet
this target. There are several important positions that have not been
filled:
 
*  Volunteer coordinator
*  Treasurer
*  Technical Services Coordinator
*  Guest liaison
*  Registration
*  Dealer room
*  Merchandising
*  Events
*  Security
 
We have coverage for the following tracks, though the coordinator(s)
for each will probably need help:
 
   Track                                Coordinator(s)
Electronic Publishing         Dave Smith, Jon Lebkowsky, Steve
                              Jackson
The Matrix                    John Quarterman, Smoot Carl-Mitchell
CyberActivism                 Ed Cavazos
CyberArts                     Bob Anderson
Technology                    Paco Xander Nathan, Mike Gallup
 
Several other general positions have been filled:
 
Co-chairpersons:                   Jon Lebkowsky
                                   Ed Cavazos
Hotel liaison:                     Steve Jackson
Info (including program book):     Vincent Omniaveritas
Hospitality suite:                 Monica Stephens
Green room:                        Suzanne Nathan
 
At the May 3 general meeting, we will discuss the conference 
and ask for volunteers. If you're interested, you can let us know
then, or (better) email one or both of the chairpersons:
      Jon Lebkowsky          jonl@tic.com
      Ed Cavazos             polekat@pro-smof.cts.com
 
Thanks!
 
Jon Lebkowsky

- ------- End of Forwarded Message


From: jbone@splat.dell.com (Jeff Bone)
Message-Id: <9205061455.AA06833@splat.dell.com>
Subject: MUD at CyberTex?
To: bazooka@ccwf.cc.utexas.edu (Bob Anderson)
Date: Wed, 6 May 92 9:55:27 CDT
Cc: cyberspace@gestalt.austin.tx.us, garnett@gestalt.austin.tx.us,
        cybertex@tic.com
In-Reply-To: <9205060458.AA11799@daisy.cc.utexas.edu>; from "Bob Anderson" at May 5, 92 11:57 pm
X-Mailer: ELM [version 2.3 PL11]


Hey there...  let me preface all this by saying I'm not volunteering for
anything (yet), just tossing some ideas out. ;)

I'm pretty involved in MUDs and feel that they are the closest thing we
have widely available to Gibsonesque cyberspace today.  Or maybe Vernor
Vinge.  Anyway...  CyberTex looks to me like it would be an ideal forum
for a MUD BOF, or MUD topic sessions, etc.  If, as the previous message
seems to indicate, we're going to have publicly available machines, it
might be worth thinking about some sort of connectivity to allow
MUDding.  

It's not uncommon to have informal MUD get togethers at SF/game cons
and so on, so a "sanctioned" event of this sort could potentially
be quite popular.  I've known MUDders who've traveled hundreds of
miles to such things in order to meet folks they only knew virtually.

The sorts of issues which the EFF is intended to address are quite
close to the hearts of MUDders;  the entire culture and way of
life is effected directly by issues of right-to-access, freedom of
speech in electronic forums, privacy, and so on.  It seems to me that
forging ties between the EFF and the large (and still growing) MUD
community could be very beneficial for both parties.  And hosting
MUD-oriented events at CyberTex would be an excellent start.

And it'd be hella fun, too. ;)


Just my $0.02...


JB


Return-Path: ccwf.cc.utexas.edu!bazooka@cs.utexas.edu
Return-Path: <ccwf.cc.utexas.edu!bazooka@cs.utexas.edu>
Received: by gestalt.austin.tx.us (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.1)
	id AA04807; Thu, 7 May 92 04:28:22 CDT
Received: from daisy.cc.utexas.edu by cs.utexas.edu (5.64/1.127) with SMTP
	id AA29404; Thu, 7 May 92 03:19:28 -0500
Received: by daisy.cc.utexas.edu (5.61/1.34/CCWF 1.18)
	id AA20455; Thu, 7 May 92 03:19:24 -0500
From: bazooka@ccwf.cc.utexas.edu (Bob Anderson)
Message-Id: <9205070819.AA20455@daisy.cc.utexas.edu>
Subject: Re: MUD at CyberTex?
To: splat.dell.com!jbone@gestalt.austin.tx.us (Jeff Bone)
Date: Thu, 7 May 92 3:19:22 CDT
Cc: cybertex@tic.com, cyberspace@gestalt.austin.tx.us
In-Reply-To: <9205061455.AA06833@splat.dell.com>; from "Jeff Bone" at May 6, 92 9:55 am
X-Mailer: ELM [version 2.3 PL11]

Jeff Bone
> 
> 
> Hey there...  let me preface all this by saying I'm not volunteering for
> anything (yet), just tossing some ideas out. ;)

<some deleted> 
 
> The sorts of issues which the EFF is intended to address are quite
> close to the hearts of MUDders;  the entire culture and way of
> life is effected directly by issues of right-to-access, freedom of
> speech in electronic forums, privacy, and so on.  It seems to me that
> forging ties between the EFF and the large (and still growing) MUD
> community could be very beneficial for both parties.  And hosting
> MUD-oriented events at CyberTex would be an excellent start.
> 
> And it'd be hella fun, too. ;)

Sounds good to me also.  I think all members of the various online 
communities should be included in some way.  It definately fits into 
the purposes of the conference as I understand it.

> If, as the previous message
> seems to indicate, we're going to have publicly available machines.

This is not firm as yet as far as I know, but I cna't imagine this event
taking place without them in some form.

Thanks for the interest!
- -- 
      Robert Anderson        |
 bazooka@well.sf.ca.us       |  "People who ask what art means are barking
  Pair O Dice BBS - Jimbo    |      up the wrong tree." - Pablo Picasso
  +1 512-451-4610 & 7117     |

Return-Path: tic.com!jonl@cs.utexas.edu
Return-Path: <tic.com!jonl@cs.utexas.edu>
Received: by gestalt.austin.tx.us (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.1)
	id AA04907; Thu, 7 May 92 08:23:02 CDT
Received: from aahsa.tic.com by cs.utexas.edu (5.64/1.127) with SMTP
	id AA08193; Thu, 7 May 92 05:41:35 -0500
Received: by aahsa.tic.com (5.65/aahsa.m4.1.11)
	id AA11831; Thu, 7 May 92 05:41:15 -0500
Date: Thu, 7 May 92 05:41:15 -0500
From: jonl@tic.com (Jon Lebkowsky)
Message-Id: <9205071041.AA11831@aahsa.tic.com>
To: bazooka@ccwf.cc.utexas.edu, splat.dell.com!jbone@gestalt.austin.tx.us
Subject: Re: MUD at CyberTex?
Cc: cyberspace@gestalt.austin.tx.us, cybertex@tic.com

>> If, as the previous message seems to indicate, we're going to have
>> publicly available machines.
>
> This is not firm yet as far as I know, but I can't imagine this event
> taking place without them in some form.

Yes, we'll have to see what we can get donated. We need suggestions from
the group as to who might be willing to donate equipment...Matt Lawrence
and I discussed yesterday how we'll probably want to set up a LAN on
site, and I'm sure we'll want modems etc.

------- End of Blind-Carbon-Copy

From csn.org!jamesp Thu May  7 16:05:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "15:47:14" "-0700" "James Powell" "jamesp@csn.org" nil "4" "Hacking in a UNIX door." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 16:05:21 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11808>; Thu, 7 May 1992 16:04:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12131>; Thu, 7 May 1992 16:01:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Thu, 7 May 1992 15:58:01 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11808>; Thu, 7 May 1992 15:57:16 PDT
Received: from teal.csn.org ([128.138.213.22]) by alpha.xerox.com with SMTP id <12176>; Thu, 7 May 1992 15:47:19 PDT
Received: by teal.csn.org id AA09145
  (5.65c/IDA-1.4.4 for MOO-Cows@Xerox.Com); Thu, 7 May 1992 16:47:16 -0600
X-NS-Transport-ID: 08002008D0FD001C6F92
Message-ID: <199205072247.AA09145@teal.csn.org>
Date:	Thu, 7 May 1992 15:47:14 -0700
From:	James Powell <jamesp@csn.org>
To:	MOO-Cows.parc@xerox.com
Subject: Hacking in a UNIX door.


Has anyone hacked (or thought about hacking) a doorway through which UNIX
applications might run?
  -James-

From minos.nmt.edu!schlake Thu May  7 16:12:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "16:05:10" "-0700" "Schlake" "schlake@minos.nmt.edu " nil "14" "Re: Hacking in a UNIX door." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 16:12:52 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12126>; Thu, 7 May 1992 16:11:25 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11828>; Thu, 7 May 1992 16:09:43 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58386>; Thu, 7 May 1992 16:06:34 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11828>; Thu, 7 May 1992 16:06:02 PDT
Received: from minos.nmt.edu ([129.138.1.5]) by alpha.xerox.com with SMTP id <11828>; Thu, 7 May 1992 16:05:25 PDT
Received: by minos.nmt.edu
	(16.6/15.6) id AA13238; Thu, 7 May 92 17:05:11 -0600
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
X-NS-Transport-ID: 08002008D0FD001C6FC5
In-Reply-to: "James Powell <jamesp@csn.org>
       \"Hacking in a UNIX door.\" (May  7,  3:47pm)tware.y.  No o"
Message-ID: <9205072305.AA13238@minos.nmt.edu>
Date:	Thu, 7 May 1992 16:05:10 -0700
From:	schlake@minos.nmt.edu (Schlake)
To:	James Powell <jamesp@csn.org>, moo-cows.parc@xerox.com
Subject: Re: Hacking in a UNIX door.

On May 7,  3:47pm, James Powell wrote:

>Has anyone hacked (or thought about hacking) a doorway through which UNIX
>applications might run?
>  -James-

I'm sure someone has.  I'm sure those people also realized what a *huge*
security hole it would be, and how much it thrash the server if it was
implemented in a "safe" way.




-- void *(*(*schlake())[])(void *);

From morticia.cnns.unt.edu!cluther Thu May  7 16:16:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "16:07:00" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "17" "Re: Hacking in a UNIX door." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 16:16:27 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12130>; Thu, 7 May 1992 16:15:06 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11808>; Thu, 7 May 1992 16:13:16 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58387>; Thu, 7 May 1992 16:09:53 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12102>; Thu, 7 May 1992 16:07:07 PDT
Received: by morticia.cnns.unt.edu id AA12812
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Thu, 7 May 1992 18:07:01 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C6FE6
In-Reply-to: "<199205072247.AA09145@teal.csn.org>; from \"James Powell\" at May 7, 92 3:47 pm"
Message-ID: <199205072307.AA12812@morticia.cnns.unt.edu>
Date:	Thu, 7 May 1992 16:07:00 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	jamesp@csn.org (James Powell)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Hacking in a UNIX door.

James Powell (>) writes:
> 
> 
> Has anyone hacked (or thought about hacking) a doorway through which UNIX
> applications might run?
>   -James-
> 

No, though we have thought about it.  However, judging from Pavel's opinion
about extensions to moo, it would never be included in any of his upgrades.


-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From aero.org!obrien Thu May  7 16:18:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "16:08:08" "-0700" "Mike O'Brien" "obrien@aero.org" nil "14" "Re: Hacking in a UNIX door." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 16:18:12 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12133>; Thu, 7 May 1992 16:17:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12129>; Thu, 7 May 1992 16:16:06 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58388>; Thu, 7 May 1992 16:13:02 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11638>; Thu, 7 May 1992 16:08:43 PDT
Received: from aerospace.aero.org ([130.221.192.10]) by alpha.xerox.com with SMTP id <11808>; Thu, 7 May 1992 16:08:16 PDT
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
	id AA10831 for moo-cows.parc@xerox.com; Thu, 7 May 1992 16:08:14 -0700
Posted-Date: Thu, 07 May 92 16:08:08 PDT
Received: from tobler.aero.org by antares.aero.org (4.1/AMS-1.0)
	id AA19014 for moo-cows.parc@xerox.com; Thu, 7 May 92 16:08:12 PDT
X-NS-Transport-ID: 08002008D0FD001C6FD4
In-Reply-to: "\"Your message of \\\"Thu, 07 May 92 15:47:14 -0900.\\\"
             <199205072247.AA09145@teal.csn.org>ical Canada"
Message-ID: <92May7.160843pdt.11638@alpha.xerox.com>
Date:	Thu, 7 May 1992 16:08:08 -0700
From:	Mike O'Brien <obrien@aero.org>
To:	moo-cows@parc.xerox.com
Subject: Re: Hacking in a UNIX door.

	
	"
To: moo-cows.PARC@Xerox.com
Message-ID: <199205072308.AA10831@aerospace.aero.org>

	I'll admit I've given it some thought.  It brings up something MUDs
haven't really dealt with in a big way in the past: system-wide security
issues.  Suddenly you have to trust the MUD at the same level you trust the
"Login" program.  Either that, or you have to arrange to run a local connection
to the MUD as a shell, somehow.

	Aside from that, it's an interesting idea.

Mike O'Brien

From csn.org!jamesp Thu May  7 17:47:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "17:39:14" "-0700" "James Powell" "jamesp@csn.org" nil "41" "Security 'n MOO 'n UNIX 'n stuff." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 17:47:49 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12162>; Thu, 7 May 1992 17:47:21 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12155>; Thu, 7 May 1992 17:45:17 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58389>; Thu, 7 May 1992 17:40:32 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12150>; Thu, 7 May 1992 17:39:59 PDT
Received: from teal.csn.org ([128.138.213.22]) by alpha.xerox.com with SMTP id <12143>; Thu, 7 May 1992 17:39:16 PDT
Received: by teal.csn.org id AA11304
  (5.65c/IDA-1.4.4 for MOO-Cows@Xerox.Com); Thu, 7 May 1992 18:39:14 -0600
X-NS-Transport-ID: 08002008D0FD001C7131
Message-ID: <199205080039.AA11304@teal.csn.org>
Date:	Thu, 7 May 1992 17:39:14 -0700
From:	James Powell <jamesp@csn.org>
To:	moo-cows.parc@xerox.com
Subject: Security 'n MOO 'n UNIX 'n stuff.


void *(*(*schlake())[])(void *); writes:
>I'm sure someone has.  I'm sure those people also realized what a *huge*
>security hole it would be, and how much it thrash the server if it was
>implemented in a "safe" way.

I wish I could believe it was such a completely rediculous proposition.

Mike O'Brien writes:
>        I'll admit I've given it some thought.  It brings up something MUDs
>haven't really dealt with in a big way in the past: system-wide security
>issues.  Suddenly you have to trust the MUD at the same level you trust the
>"Login" program.  Either that, or you have to arrange to run a local connection
>to the MUD as a shell, somehow.
>       Aside from that, it's an interesting idea.

Lots of programs must be trusted at the same level as login.

>dave@ipac.caltech.edu writes:
>Hooks to run shell commands from the server are not a good idea.  Security
>risks are the biggest reason I'd never run a server with this feature
>(BUG!).  You are much better hacking your client to do this locally - it's
>hard to see why you need to use the server's resources to do this anyway.
>Many clients, in fact, already have this capability.

This MOO can't count on clients, but must provide UNIX services.  It is that,
or have UNIX provide MOO as a service.  Personally, I think your average
person would rather be faced with MOO with UNIX as an option rather than
UNIX as MOO with an option.

>Clay W. Luther writes:
>No, though we have thought about it.  However, judging from Pavel's opinion
>about extensions to moo, it would never be included in any of his upgrades.

That is too bad.  What is Pavel's policy about including extensions to MOO
in future releases?

Anyway, ya'll can tell I'm not as concerned with the security aspects of the
problem as I am with the implementation difficulties.  Those of you who have
hacked the server: do you believe this would be a fairly simple mod?
  -James-

From morticia.cnns.unt.edu!cluther Thu May  7 17:55:55 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "17:48:45" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "14" "Re: Security 'n MOO 'n UNIX 'n stuff." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 17:55:49 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12157>; Thu, 7 May 1992 17:55:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12158>; Thu, 7 May 1992 17:53:19 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58390>; Thu, 7 May 1992 17:49:14 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12158>; Thu, 7 May 1992 17:48:53 PDT
Received: by morticia.cnns.unt.edu id AA13455
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Thu, 7 May 1992 19:48:46 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C7156
In-Reply-to: "<199205080039.AA11304@teal.csn.org>; from \"James Powell\" at May 7, 92 5:39 pmo"
Message-ID: <199205080048.AA13455@morticia.cnns.unt.edu>
Date:	Thu, 7 May 1992 17:48:45 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	jamesp@csn.org (James Powell)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Security 'n MOO 'n UNIX 'n stuff.

James Powell (>) writes:

> Anyway, ya'll can tell I'm not as concerned with the security aspects of the
> problem as I am with the implementation difficulties.  Those of you who have
> hacked the server: do you believe this would be a fairly simple mod?

It goes beyond simple.  It is trivial.
Really.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From parc.xerox.com!pavel Thu May  7 18:52:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "18:46:14" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "57" "Re: Security 'n MOO 'n UNIX 'n stuff." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 18:52:37 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12165>; Thu, 7 May 1992 18:51:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12129>; Thu, 7 May 1992 18:50:26 PDT
Received: by lambda.parc.xerox.com id <58392>; Thu, 7 May 1992 18:46:21 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001C71F4
In-Reply-to: <199205080039.AA11304@teal.csn.org>
Message-ID: <92May7.184621pdt.58392@lambda.parc.xerox.com>
References: <199205080039.AA11304@teal.csn.org>
Date:	Thu, 7 May 1992 18:46:14 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Re: Security 'n MOO 'n UNIX 'n stuff.

James Powell says:
   >Clay W. Luther writes:
   >No, though we have thought about it.  However, judging from Pavel's opinion
   >about extensions to moo, it would never be included in any of his upgrades.

   That is too bad.  What is Pavel's policy about including extensions to MOO
   in future releases?

Clay is confused and overreacting to earlier messages of mine.  I welcome
suggestions for server enhancements, all the more if they come with detailed
specifications and/or working implementations.  Even if you send me code,
though, and even if I agree that the provided functionality is a good idea, I
don't promise to use your code or even your interface to that functionality.  I
may think that there's a simpler or easier-to-use or more general way to get
the same effect.

   Anyway, ya'll can tell I'm not as concerned with the security aspects of the
   problem as I am with the implementation difficulties.  Those of you who have
   hacked the server: do you believe this would be a fairly simple mod?

It depends upon the functionality you want to provide to the MOO programmer.
In any case, I must disagree with Clay's characterization of the mod as
`trivial'.

The simplest interface I can imagine is to reflect the ANSI C `system()'
procedure in MOO as a built-in function.  That is, you could say
	system("cp foo bar")
to copy file `foo' to the new name `bar'.  The implementation in the server
would be quite simple: it would simply turn around and call the ANSI C function
and be done with it.

Leaving aside issues concerning the environment in which such commands run
(whose permissions, what working directory, etc.), there are several
significant problems with this approach:
	+ The server will be doing nothing at all while the command is running,
	  including not running any other tasks.
	+ If the command takes more seconds than the current task has left,
	  then the task will immediately abort after the command finishes.
	+ There is no provision for giving input to the command or getting
	  output back.  One could, I suppose, take a list-of-strings argument
	  to system(), to be used as the standard input of the command, and
	  return a list-of-strings result, gathered from the standard output,
	  all this implemented by adding `< tmp-input-file > tmp-output-file'
	  onto the end of the command before passing it off to system(), but
	  this would only work at all reasonably for `batch-style' commands.
To my mind, even if the solution proposed in the third of these points was good
enough for the application in question, the first two points would be fatal for
any multi-user situation.

To implement a more generally-useful solution, the server would need to provide
functionality much like the GNU Emacs `subprocess' stuff, in which commands are
forked off in the background, input can be given to them in incremental bursts,
output comes in asynchronously either to a waiting task or by starting a server
task, etc.  While this is not particularly difficult in theory, it certainly
falls nowhere near `trivial'.

	Pavel

From morticia.cnns.unt.edu!cluther Thu May  7 19:36:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "19:29:36" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "71" "Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 19:36:26 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12163>; Thu, 7 May 1992 19:35:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12168>; Thu, 7 May 1992 19:34:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58393>; Thu, 7 May 1992 19:30:08 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12129>; Thu, 7 May 1992 19:29:41 PDT
Received: by morticia.cnns.unt.edu id AA13771
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Thu, 7 May 1992 21:29:37 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C7244
Message-ID: <199205080229.AA13771@morticia.cnns.unt.edu>
Date:	Thu, 7 May 1992 19:29:36 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)

Pavel Curtis (>) writes:

> James Powell says:
>    >Clay W. Luther writes:
>    >No, though we have thought about it.  However, judging from Pavel's opinion
>    >about extensions to moo, it would never be included in any of his upgrades.
> 
>    That is too bad.  What is Pavel's policy about including extensions to MOO
>    in future releases?
> 
> Clay is confused and overreacting to earlier messages of mine.  I welcome
> suggestions for server enhancements, all the more if they come with detailed
> specifications and/or working implementations.  Even if you send me code,
> though, and even if I agree that the provided functionality is a good idea, I
> don't promise to use your code or even your interface to that functionality.  I

I am neither confused nor overreacting and, in general, I would resent such
characterizations of my moods by someone who doesn't even know me.

My statement reflected my meager knowledge of how you think.  And rather
accurately.  I stated, in context of that message, that you would never include
that proposed extension to moo.  I think, as the rest of your reply indicates,
you agree with this assessment.

> It depends upon the functionality you want to provide to the MOO programmer.
> In any case, I must disagree with Clay's characterization of the mod as
> `trivial'.

A call out to unix is a trivial matter.  Why, however, you'd use system() 
I don't know.  A call out to unix from within moo is not as trivial as a
system() call, of course, but it is *not* difficult.

Give me credit, Pavel.  You aren't the only proferssional unix programmer
alive.

The solution *is* trivial, conceptually.  The code is not that difficult,
either, ie, trivial.  It's my job to write chunks of code that can do 
*precisely* what the original poster described.  Do you think you know my job 
better than I do, Pavel?  I'm sorry if I was under the misconception that
Unix made such ipc easy.

> The simplest interface I can imagine is to reflect the ANSI C `system()'
> procedure in MOO as a built-in function.  That is, you could say
> 	system("cp foo bar")

Simple, and borderline innane, for the obvious reasons you stated.

> 	+ There is no provision for giving input to the command or getting
> 	  output back.  One could, I suppose, take a list-of-strings argument

Ever heard of signals?  
Ever heard of pipes?  
Ever heard of sockets?  
Ever heard of forking? 
I know you have.  I have, too, and I can think up many wonderful incantations
using these tools.

Refer to pages 108-109, 170 and Chapter 6 in Unix Network Programming 
(Stevens) for clues.

These are the basic tools for the unix programmer.

So, sorry about the tirade, but I don't like being mischaracterized or 
slandered, or being told something contrary to what I know is true.  And 
contrary to what you may be thinking, I am not angry.  Just downright annoyed.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From phyvs1.anu.edu.au!dxb105 Thu May  7 20:21:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "10:13:03" "-0700" "David Bofinger" "dxb105@phyvs1.anu.edu.au" nil "18" "MOONIX" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 7 May 1992 20:21:45 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12170>; Thu, 7 May 1992 20:21:15 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12165>; Thu, 7 May 1992 20:19:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58394>; Thu, 7 May 1992 20:15:06 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12158>; Thu, 7 May 1992 20:14:51 PDT
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <12158>; Thu, 7 May 1992 20:14:16 PDT
Received: by phys.anu.edu.au (MX V2.3) id 6132; Fri, 08 May 1992 13:13:03 EDT
X-NS-Transport-ID: 08002008D0FD001C727A
Message-ID: <0095A459.81B8BC20.6132@phys.anu.edu.au>
Date:	Fri, 8 May 1992 10:13:03 -0700
From:	David Bofinger <dxb105@phyvs1.anu.edu.au>
To:	moo-cows.parc@xerox.com
cc:	dxb105@phyvs1.anu.edu.au
Subject: MOONIX

>Has anyone hacked (or thought about hacking) a doorway through which UNIX
>applications might run?
>  -James-

I'm sure Pavel has thought of this, around about three o'clock in the morning,
just before he wakes up screaming in a cold sweat. What's the application,
though? I can imagine it's a very general purpose change that will tend to
accumulate applications with time, but it seems odd to me that nobody has
mentioned what it would be used for. Knowing what the legitimate applications
were would surely ease the security issues debate, once the Clay-Pavel flamewar
has died down.

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
------------------------------------------------------------------------------
"The man of whom Hannibal Lecter said, 'Oh my, what a nasty person.'"
							-- Terry Pratchett

From xerox.com!parc.xerox.com.PARC Fri May  8 03:31:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "7" "May" "1992" "21:08:34" "-0700" "Michael Richardson" "mcr@latour.sandelman.ocunix.on.ca " nil "35" "Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 8 May 1992 03:31:23 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11640>; Fri, 8 May 1992 03:30:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11645>; Fri, 8 May 1992 03:28:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58395>; Fri, 8 May 1992 03:23:55 -0700
Received: from mail.uunet.ca ([142.77.1.1]) by alpha.xerox.com with SMTP id <11640>; Fri, 8 May 1992 03:23:18 PDT
Received: from ocunix by mail.uunet.ca with UUCP id <10202>; Fri, 8 May 1992 06:23:04 -0400
Received: by micor.OCUnix.On.Ca (smail2.5)
	id AA11007; 8 May 92 00:51:15 EDT (Fri)
Received: by sandelman.ocunix.on.ca id AA10338
  (5.65a/IDA-1.4.2 for moo-cows@parc.xerox.com); Fri, 8 May 92 00:08:42 -0400
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-NS-Transport-ID: 08002008D0FD001C7546
In-Reply-to: "Clay Luther <cluther@morticia.cnns.unt.edu>
       \"Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)\" (May  7, 10:29pm)es f"
Message-ID: <9205080408.AA10338@sandelman.ocunix.on.ca>
Date:	Thu, 7 May 1992 21:08:34 -0700
From:	mcr@latour.sandelman.ocunix.on.ca (Michael Richardson)
Sender: parc.xerox.com.PARC@xerox.com
To:	Clay Luther <cluther@morticia.cnns.unt.edu>, moo-cows@parc.xerox.com
Subject: Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)

On May 7, 10:29pm, Clay Luther wrote:
} Ever heard of signals?  
} Ever heard of pipes?  
} Ever heard of sockets?  
} Ever heard of forking? 

  One thing comes to mind with forking --- a month or two ago there
was a debate in comp.unix.internals (I think) about how to invoke a
process without doing fork() -- the poster was worried that
duplicating his immense process space would take significant time.
Copy-On-Write was brought as the saviour, and then the poster
suggested that even setting all those region descriptors may take a
long time for a huge process.  MOO sounds like a good example :-)
  
} I know you have.  I have, too, and I can think up many wonderful incantations
} using these tools.

  I would be really curious as to *what* it is that you have in mind.

  A co-process might be created in a chroot'ed environment to act as a
process `server' --- open_network_connection() might be just what is
really needed here. (perhaps an option to use an AF_INET socket
instead thus guaranteeing security of this socket?)


  

-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca     Bell: (613) 237-5629
SCHOOL: 192228@physics.carleton.ca      




From encore.com!jdarcy Fri May  8 06:11:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "06:03:43" "-0700" "Jeff d'Arcy" "jdarcy@encore.com" nil "66" "Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 8 May 1992 06:11:45 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11701>; Fri, 8 May 1992 06:10:56 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11694>; Fri, 8 May 1992 06:09:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58396>; Fri, 8 May 1992 06:04:42 -0700
Received: from gould.encore.com ([129.91.131.1]) by alpha.xerox.com with SMTP id <11656>; Fri, 8 May 1992 06:04:08 PDT
Received: from walrus.encore.COM by gould.encore.com with SMTP
	  id AA13761 (5.64+/UK-2.1-920501); Fri, 8 May 92 09:04:08 -0400
Received: by walrus.encore.com id AA02585 (5.59/UK-2.1-910806);
	  Fri, 8 May 92 09:03:43 EDT
X-NS-Transport-ID: 08002008D0FD001C7654
Message-ID: <2585.9205081303@walrus.encore.com>
Date:	Fri, 8 May 1992 06:03:43 -0700
From:	Jeff d'Arcy <jdarcy@encore.com>
To:	cluther@morticia.cnns.unt.edu, moo-cows@parc.xerox.com
Subject: Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)

>From: Clay Luther <cluther@morticia.cnns.unt.edu>
>Message-Id: <199205080229.AA13771@morticia.cnns.unt.edu>
>Subject: Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)
>Date: 	Thu, 7 May 1992 19:29:36 PDT
>
>Give me credit, Pavel.  You aren't the only proferssional unix programmer
>alive.

No, he's not.  I'm another one (and, I dare say, one with greater variety of
experience than most).  I think Pavel's points were very good ones, whereas
you seem to be doing nothing more constructive than taking pot-shots.

>> The simplest interface I can imagine is to reflect the ANSI C `system()'
>> procedure in MOO as a built-in function.  That is, you could say
>> 	system("cp foo bar")
>
>Simple, and borderline innane, for the obvious reasons you stated.
>
>> 	+ There is no provision for giving input to the command or getting
>> 	  output back.  One could, I suppose, take a list-of-strings argument
>
>Ever heard of signals?  
>Ever heard of pipes?  
>Ever heard of sockets?  
>Ever heard of forking? 
>I know you have.  I have, too, and I can think up many wonderful incantations
>using these tools.

Based on what I'm seeing here, I'm surprised you have a job programming.  Your
inappropriate condescension and your deliberate attempt to misunderstand what
Pavel said in the interests of pursuing your personal grudge would get you
thrown out of any development organization I've worked at.  That said, I'll go
one better than you did and try to provide some answers to your questions.

	1. What we were originally talking about was a UNIX *command* level
	interface, not API level as you seem to be suggesting (I'm sure I don't
	need to ask that you correct me if I'm wrong).  There's a difference at
	both the conceptual and practical levels.

	2. Forking does avoid *one* of the problems Pavel mentioned - that of
	stopping the server while the command executes.  When and where to
	wait(2) for the forked process, however, may be a matter of some
	delicacy.  More importantly, all the world's not UNIX.  MOO is, I
	believe, supposed to run on DOS too.  Last time I looked, DOS didn't
	have fork(2).  I'm sure we could debate for a while about the wisdom of
	providing a UNIX-only feature in MOO.

	3. No matter how you cut it, a solution that involves forking, dealing
	wih signals, input and output, etc. is far from trivial.  It may still
	be relatively simple, but the statement that Pavel rightly challenged
	is that it's trivial.  You seem to regard this discussion as a battle,
	but you may want to change your attitude now that you've "lost".

>So, sorry about the tirade, but I don't like being mischaracterized or 
>slandered, or being told something contrary to what I know is true.  And 
>contrary to what you may be thinking, I am not angry.  Just downright annoyed.

Pavel's comment about your attitude may have been inappropriate in the context
at the time, but its truth seems to've been validated by your response.  You
may be a very talented programmer, and you may have some legitimate gripes
about how Pavel has responded to your suggestions for improvement.  However, as
any book on negotiation skills (I wish one were required reading for engineers)
will tell you, attacks such as yours are more likely to hurt your case than
help it.  Never alienate someone from whom you expect concessions.

	jeff

From morticia.cnns.unt.edu!cluther Fri May  8 08:31:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "08:25:01" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "30" "Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 8 May 1992 08:31:51 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11704>; Fri, 8 May 1992 08:31:16 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11708>; Fri, 8 May 1992 08:29:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Fri, 8 May 1992 08:25:53 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11704>; Fri, 8 May 1992 08:25:29 PDT
Received: by morticia.cnns.unt.edu id AA15256
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Fri, 8 May 1992 10:25:02 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C7861
In-Reply-to: "<9205080408.AA10338@sandelman.ocunix.on.ca>; from \"Michael Richardson\" at May 8, 92 12:08 amis"
Message-ID: <199205081525.AA15256@morticia.cnns.unt.edu>
Date:	Fri, 8 May 1992 08:25:01 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	mcr@latour.sandelman.ocunix.on.ca (Michael Richardson)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)

Michael Richardson (>) writes:
> 
> On May 7, 10:29pm, Clay Luther wrote:
> } Ever heard of signals?  
> } Ever heard of pipes?  
> } Ever heard of sockets?  
> } Ever heard of forking? 
> 
>   One thing comes to mind with forking --- a month or two ago there
> was a debate in comp.unix.internals (I think) about how to invoke a
> process without doing fork() -- the poster was worried that
> duplicating his immense process space would take significant time.
> Copy-On-Write was brought as the saviour, and then the poster
> suggested that even setting all those region descriptors may take a
> long time for a huge process.  MOO sounds like a good example :-)

Yah, moo in it's current inception would be a terrible thing to fork, but I
am thinking towards Pavel's planned upgrade where the db is not stored in
memory.  Or, like I indicated, you might write a Moo-Unix-Gateway server that
sits on some socket (moosocket+1 would be good ;))  It waits for moo to open
a connection to it.  Almost like an rsh, of which you may find a fine example
in Stevens [Chapter 14].  

Sorry about the smoke in Moo cows.  I was just really annoyed.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From morticia.cnns.unt.edu!cluther Fri May  8 08:43:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "08:38:01" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "40" "Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 8 May 1992 08:43:56 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11724>; Fri, 8 May 1992 08:43:03 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11710>; Fri, 8 May 1992 08:41:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Fri, 8 May 1992 08:38:57 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11705>; Fri, 8 May 1992 08:38:36 PDT
Received: by morticia.cnns.unt.edu id AA15386
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Fri, 8 May 1992 10:38:02 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C789D
In-Reply-to: "<2585.9205081303@walrus.encore.com>; from \"Jeff d'Arcy\" at May 8, 92 9:03 am"
Message-ID: <199205081538.AA15386@morticia.cnns.unt.edu>
Date:	Fri, 8 May 1992 08:38:01 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	jdarcy@encore.com (Jeff d'Arcy)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: Security 'n MOO 'n UNIX 'n stuff. (fwd)

Jeff d'Arcy (>) writes:

> >Give me credit, Pavel.  You aren't the only proferssional unix programmer
> >alive.
> 
> No, he's not.  I'm another one (and, I dare say, one with greater variety of
> experience than most).  I think Pavel's points were very good ones, whereas
> you seem to be doing nothing more constructive than taking pot-shots.

Well, you seem to have read a different letter than I did.  I have no personal
gripe or grudge against Pavel.

Nor did I ever say Pavel's points weren't valid or good.  In fact, I agreed that
within the context of his example his points were correct.

I was just terribly offended that he had called me wrong, confused, and 
overreactive in one breath, especially when I was not any of them.  I kept 
asking myself "Who does he think he's talking to?"

> Pavel's comment about your attitude may have been inappropriate in the context
> at the time, but its truth seems to've been validated by your response.  You
> may be a very talented programmer, and you may have some legitimate gripes
> about how Pavel has responded to your suggestions for improvement.  However, as

I have learned not expect anything from persons who think they understand
everything.  And, like I said, I have no grudge or gripe *with* Pavel.  Pavel 
is Pavel, and nothing I say or do will change that, just like Clay is Clay 
(although I have to ability to correct and re-evaluate my behavior).  I may
not agree with Pavel's methods or his opinions.  But, I do not feel I have to
stand around and be dengrated by someone who has never even taken the time to
talk to get to know me.

As I said at the end of my message, I apologize that I got angry, but I also
feel, within the context of that message, that I was justified.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From att1.mankato.msus.edu!nop Fri May  8 10:39:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "10:28:04" "-0700" "nop@att1.mankato.msus.edu" "nop@att1.mankato.msus.edu" nil "23" "Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 8 May 1992 10:39:22 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11672>; Fri, 8 May 1992 10:38:14 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11723>; Fri, 8 May 1992 10:36:16 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Fri, 8 May 1992 10:33:00 -0700
Received: from att1.Mankato.MSUS.EDU ([134.29.1.7]) by alpha.xerox.com with SMTP id <11718>; Fri, 8 May 1992 10:32:29 PDT
Received:  by att1.Mankato.MSUS.EDU (5.59/25-eef)
	id AA02877; Fri, 8 May 92 12:28:04 CDT
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	Jay A.Carlson <nop@att1.Mankato.MSUS.EDU>
		^    ^-illegal period in phrase
		 \-phrases containing '.' must be quoted
X-NS-Transport-ID: 08002008D0FD001C7ACA
In-Reply-to: "Jeff d'Arcy's message of Fri, 8 May 1992 06:03:43 PDT <2585.9205081303@walrus.encore.com>"
Message-ID: <9205081728.AA02877@att1.Mankato.MSUS.EDU>
Date:	Fri, 8 May 1992 10:28:04 -0700
From:	nop@att1.mankato.msus.edu
To:	jdarcy@encore.com
cc:	cluther@morticia.cnns.unt.edu, moo-cows@parc.xerox.com
Subject: Security 'n MOO 'n UNIX 'n stuff. (fwd)

Jeff d'Arcy writes:
> 2. Forking does avoid *one* of the problems Pavel mentioned - that of
> stopping the server while the command executes.  When and where to
> wait(2) for the forked process, however, may be a matter of some
> delicacy.  More importantly, all the world's not UNIX.  MOO is, I
> believe, supposed to run on DOS too.  Last time I looked, DOS didn't
> have fork(2).  I'm sure we could debate for a while about the wisdom of
> providing a UNIX-only feature in MOO.

Although most of the MOO server appears to be quite portable, parts of
it are targeted only at Unix.  Providing similar functionality can be
troublesome.  bsd_network.c is, of course, not portable, and I seem to
remember some odd BSDism in server.c.  fork is already used in the
server to do checkpointing.  In the my Amiga and Zippy's MS-DOS port,
the server does checkpointing in the main thread, and thus pauses for
the duration of the checkpoint.

Even though I am enthusiastic about the server running on operating
systems other than BSD Unix, I don't want MOO development driven by
the lowest common denominator.

  // Jay Carlson/Jonny
\X/  nop@att1.mankato.msus.edu

From bds.bds.com!mg Fri May  8 10:52:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "10:42:26" "-0700" "Mike Gallaher" "mg@bds.bds.com" nil "17" "Re: Hacking in a UNIX door." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 8 May 1992 10:52:39 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11729>; Fri, 8 May 1992 10:52:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11693>; Fri, 8 May 1992 10:47:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58399>; Fri, 8 May 1992 10:44:09 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11724>; Fri, 8 May 1992 10:43:41 PDT
Received: from bds.bds.com ([192.107.237.1]) by alpha.xerox.com with SMTP id <11731>; Fri, 8 May 1992 10:42:37 PDT
Received: by bds.bds.com (5.61/1.34)
	id AA05010; Fri, 8 May 92 13:42:28 -0400
X-NS-Transport-ID: 08002008D0FD001C7AEF
In-Reply-to: "Your message of Thu, 7 May 1992 15:47:14 PDT"
Message-ID: <CMM-RU.1.0.705346946.mg@bds>
Date:	Fri, 8 May 1992 10:42:26 -0700
From:	Mike Gallaher <mg@bds.bds.com>
To:	James Powell <jamesp@csn.org>
cc:	MOO-Cows.parc@xerox.com
Subject: Re: Hacking in a UNIX door.

There is a well-known way to provide access to external shells
(command interpreters) in any moo, or any mud for that matter,
with no server modifications.

Write a program that logs into the moo as a player, and sits in
a room waiting for people to come in and say, for instance,
"ls", to which it would respond

+++
5410			Image67053		comp
A			Image78696		convergent
B			Image89858		corge
---

To restrict access to it, restrict the room as you would any other.

mg

From steamer.clam.com!jeff Fri May  8 10:58:08 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "10:44:28" "-0700" "Jeff d'Arcy" "jeff@steamer.clam.com " nil "31" "Re:  Security 'n MOO 'n UNIX 'n stuff. (fwd)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 8 May 1992 10:57:54 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11724>; Fri, 8 May 1992 10:57:14 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11720>; Fri, 8 May 1992 10:55:02 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58400>; Fri, 8 May 1992 10:50:15 -0700
Received: from steamer.clam.com ([140.186.81.143]) by alpha.xerox.com with SMTP id <11730>; Fri, 8 May 1992 10:48:05 PDT
Received: by steamer.clam.com (AIX 3.1/UCB 5.61/4.03)
          id AA72805; Fri, 8 May 92 13:44:28 -0400
X-NS-Transport-ID: 08002008D0FD001C7B2F
Message-ID: <9205081744.AA72805@steamer.clam.com>
Date:	Fri, 8 May 1992 10:44:28 -0700
From:	jeff@steamer.clam.com (Jeff d'Arcy)
To:	jdarcy@encore.com, nop@att1.mankato.msus.edu
cc:	moo-cows@parc.xerox.com
Subject: Re:  Security 'n MOO 'n UNIX 'n stuff. (fwd)

>Date: Fri, 8 May 92 12:28:04 CDT
>From: Jay A. Carlson <nop@att1.Mankato.MSUS.EDU>
>Message-Id: <9205081728.AA02877@att1.Mankato.MSUS.EDU>
>Subject: Security 'n MOO 'n UNIX 'n stuff. (fwd)
>
>Jeff d'Arcy writes:
>> 2. Forking does avoid *one* of the problems Pavel mentioned - that of
>> stopping the server while the command executes.  When and where to
>> wait(2) for the forked process, however, may be a matter of some
>> delicacy.  More importantly, all the world's not UNIX.  MOO is, I
>> believe, supposed to run on DOS too.  Last time I looked, DOS didn't
>> have fork(2).  I'm sure we could debate for a while about the wisdom of
>> providing a UNIX-only feature in MOO.
>
>Although most of the MOO server appears to be quite portable, parts of
>it are targeted only at Unix.  Providing similar functionality can be
>troublesome.  bsd_network.c is, of course, not portable, and I seem to
>remember some odd BSDism in server.c.  fork is already used in the
>server to do checkpointing.  In the my Amiga and Zippy's MS-DOS port,
>the server does checkpointing in the main thread, and thus pauses for
>the duration of the checkpoint.
>
>Even though I am enthusiastic about the server running on operating
>systems other than BSD Unix, I don't want MOO development driven by
>the lowest common denominator.

Agreed.  It's a decision that should not be made blindly, lest we render MOO
(perhaps buildable but practically) unusable elsewhere, but I agree that some
UNIX-only features such as this one are probably desirable.

	jeff

From kirk.vax.aston.ac.uk!WHEELERC Fri May  8 14:26:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "07:49:00" "-0700" "\"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES.\"" "WHEELERC@kirk.vax.aston.ac.uk" nil "28" "RE: the Impending peril of a Flame War" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Fri, 8 May 1992 14:26:27 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11757>; Fri, 8 May 1992 14:25:57 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11760>; Fri, 8 May 1992 14:23:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58401>; Fri, 8 May 1992 14:21:33 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11761>; Fri, 8 May 1992 14:21:13 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11760>; Fri, 8 May 1992 14:20:08 PDT
Via: kirk.vax.aston.ac.uk; Fri, 8 May 1992 15:48:46 +0100
X-NS-Transport-ID: 08002008D0FD001C7F19
Message-ID: <92May8.142008pdt.11760@alpha.xerox.com>
Date:	Fri, 8 May 1992 07:49:00 -0700
From:	"THE BIG FAT CLOWN, WITH A BIG RED BOOK OF BAAD JOKES." <WHEELERC@kirk.vax.aston.ac.uk>
To:	MOO-COWS <MOO-COWS@xerox.com>
Subject: RE: the Impending peril of a Flame War


Hey guys, 

Let the bad feelings sit on the back burner and simmer down a bit.  I don't 
think anyone is doubting that Pavel & Clay know what they're doing, I just 
think a couple of things were misread, probably on a terminal that was 
starting to go fuzzy round the edges at 3am in the morning.

I've read some of the messages, and in particular the one relating to Unix
calls by the MOO, from Pavel, and Clay's reply.  It seems that what was 
written by one could be taken in the wrong way by the other. 

As far as I can see both main players, and any others who are feeling fiesty,
should re-read those posts, and think about the possibility that there could
be a non-inflammatory meaning.

If you can't do that, route any flames via me, (wheelerc@spock.aston.ac.uk 
should do it) and I will pass them on, and should any relavant material 
turn up I will post it to MOO-Cows.

I can't see that this solution would be needed, as two professionals ought to
wake up and realise that there was originally no criticism being thrown.


Colin

	... anything for a quiet life ...


From csn.org!jamesp Fri May  8 16:28:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "16:20:06" "-0700" "James Powell" "jamesp@csn.org" nil "81" "<creeeeeek> the door opens a crack..." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Fri, 8 May 1992 16:28:22 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11806>; Fri, 8 May 1992 16:27:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11802>; Fri, 8 May 1992 16:25:51 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Fri, 8 May 1992 16:21:30 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11804>; Fri, 8 May 1992 16:20:50 PDT
Received: from teal.csn.org ([128.138.213.22]) by alpha.xerox.com with SMTP id <11799>; Fri, 8 May 1992 16:20:08 PDT
Received: by teal.csn.org id AA12690
  (5.65c/IDA-1.4.4 for MOO-Cows@Xerox.Com); Fri, 8 May 1992 17:20:06 -0600
X-NS-Transport-ID: 08002008D0FD001C8106
Message-ID: <199205082320.AA12690@teal.csn.org>
Date:	Fri, 8 May 1992 16:20:06 -0700
From:	James Powell <jamesp@csn.org>
To:	MOO-COWS.PARC@xerox.com
Subject: <creeeeeek> the door opens a crack...

Well, here we go again!

Jeff d'Arcy <jdarcy@encore.com> writes:
>1. What we were originally talking about was a UNIX *command* level
>interface, not API level as you seem to be suggesting (I'm sure I don't
>need to ask that you correct me if I'm wrong).  There's a difference at
>both the conceptual and practical levels.

I am indeed interested in a command level (shell and beyond) door.

This certainly sounds like a step in the right direction:

Michael Richardson writes:
>  A co-process might be created in a chroot'ed environment to act as a
>process `server' --- open_network_connection() might be just what is
>really needed here. (perhaps an option to use an AF_INET socket
>instead thus guaranteeing security of this socket?)

But then again, so does this:

Mike Gallaher <mg@bds.bds.com> writes:
>There is a well-known way to provide access to external shells
>(command interpreters) in any moo, or any mud for that matter,
>with no server modifications.
>
>Write a program that logs into the moo as a player, and sits in
>a room waiting for people to come in and say, for instance,
>"ls", to which it would respond
>[ls response omitted]

And they are certainly different approaches.

David Bofinger <dxb105@phyvs1.anu.edu.au> writes:
>I'm sure Pavel has thought of this, around about three o'clock in the morning,
>just before he wakes up screaming in a cold sweat. What's the application,
>though? I can imagine it's a very general purpose change that will tend to
>accumulate applications with time, but it seems odd to me that nobody has
>mentioned what it would be used for. Knowing what the legitimate applications
>were would surely ease the security issues debate, once the Clay-Pavel flamewar
>has died down.

Hmm, ok.  The first two applications I need this for are newsreading and
error correcting file transfers.

Pavel Curtis <pavel@parc.xerox.com> writes:
>> James Powell writes:
>>  Anyway, ya'll can tell I'm not as concerned with the security aspects of the
>>  problem as I am with the implementation difficulties.  Those of you who have
>>  hacked the server: do you believe this would be a fairly simple mod?
>
>It depends upon the functionality you want to provide to the MOO programmer.
>In any case, I must disagree with Clay's characterization of the mod as
`trivial'.
>
>The simplest interface I can imagine is to reflect the ANSI C `system()'
>procedure in MOO as a built-in function.  That is, you could say
>	system("cp foo bar")
>to copy file `foo' to the new name `bar'.  The implementation in the server
>would be quite simple: it would simply turn around and call the ANSI C function
>and be done with it.
>
>Leaving aside issues concerning the environment in which such commands run
>(whose permissions, what working directory, etc.), there are several
>significant problems with this approach:
>[list of significant problems omitted]
>
>To my mind, even if the solution proposed in the third of these points was good
>enough for the application in question, the first two points would be fatal for
>any multi-user situation.
>
>To implement a more generally-useful solution, the server would need to provide
>functionality much like the GNU Emacs `subprocess' stuff, in which commands are
>[summary of GNU Emacs subprocess functionality omitted]

I'll need interactive 8-bit streams, so no system() approach is going to cut it.
It is looking like a pretty hairy project, but it is one that simply must be
done.  I would love to get comments on the suggestions from Mike Gallaher,
Michael Richardson, and Pavel, plus any additional ideas the MOO-crew
("Cowdependant no more!" - seen on T-Shirt) can put forth.  Thanks for your
interest in this problem, and your insightful commentary!
  -James-

From senex.unh.edu!unhtel!morwyn!forrie Sat May  9 10:57:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "9" "May" "1992" "09:58:52" "-0700" "Forrie Aldrich" "forrie@morwyn.uucp" nil "21" "Info sought" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 9 May 1992 10:57:46 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11850>; Sat, 9 May 1992 10:56:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11847>; Sat, 9 May 1992 10:54:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 9 May 1992 10:50:50 -0700
Received: from senex.unh.edu ([132.177.128.103]) by alpha.xerox.com with SMTP id <11851>; Sat, 9 May 1992 10:50:33 PDT
Received: by senex.unh.edu id AA06745
  (5.65c+/IDA-1.4.4 for parc.xerox.com!moo-cows); Sat, 9 May 1992 13:52:23 -0400
Received: by unhtel.unh.edu (smail2.5R)
	id AA29334; 9 May 92 13:51:36 EDT (Sat)
Received: by morwyn.UUCP id AA01715
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Sat, 9 May 1992 12:58:52 -0400
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
X-NS-Transport-ID: 08002008D0FD001C85DE
Message-ID: <199205091658.AA01715@morwyn.UUCP>
Date:	Sat, 9 May 1992 09:58:52 -0700
From:	Forrie Aldrich <forrie@morwyn.uucp>
Sender: unhtel!morwyn!forrie@senex.unh.edu
To:	moo-cows@parc.xerox.com
Subject: Info sought

Er.. sorry to interrupt:

I don't get the groups rec.* or alt.* (have a small node), but would like
to get ahold of the rec.games.mud FAQ list.  I hear that LPMUD has an
interesting language interface as well.  

And out of curiosity, have there been any others out there working on
porting the networking code of LambdaMOO to a non-networking machine?  I
know that TinyMUD (which I don't really care for) works fine in this
sense.  I wonder if LPMUD would.  

Any info would be greatly appreciated.  Thanks.

Forrest.

-- 
           -----------        Forrest Aldrich         -----------
           -------     morwyn!forrie@unhtel.unh.edu       -------
           ----                                              ---- 
           --        VISION GRAPHICS -- Dover, NH - USA        --
           ------------------------------------------------------

From ee.ualberta.ca!daum Sat May  9 19:03:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "9" "May" "1992" "18:56:14" "-0700" "Tanya Louise Daum" "daum@ee.ualberta.ca" nil "10" "Help wanted!" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 9 May 1992 19:03:22 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11871>; Sat, 9 May 1992 19:02:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11872>; Sat, 9 May 1992 19:00:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 9 May 1992 18:57:01 -0700
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11871>; Sat, 9 May 1992 18:56:35 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA26888; Sat, 9 May 92 19:56:14 -0600
X-NS-Transport-ID: 08002008D0FD001C87B6
Message-ID: <92May9.185635pdt.11871@alpha.xerox.com>
Date:	Sat, 9 May 1992 18:56:14 -0700
From:	Tanya Louise Daum <daum@ee.ualberta.ca>
To:	MOO-cows@parc.xerox.com
Subject: Help wanted!


  I'm looking for experienced moo programmers with a desire to build in a Ninety-Eighty-Four themed MOO.

  As of now we have Nyssa and Morhpeus and I (Opiate) as well as some who may soon sign on.  We are looking for more people to work on various pieces of the system.

  If you are experienced with MOO and have a desire to try something new, please contact us!  We are especially interested in those with RPG experience (programming or GMing.)

  Thanks
      Opiate


From xerox.com!parc.xerox.com.PARC Sun May 10 16:19:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "10" "May" "1992" "11:48:35" "-0700" "Michael Richardson" "mcr@latour.sandelman.ocunix.on.ca " nil "47" "Re: <creeeeeek> the door opens a crack..." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 10 May 1992 16:19:20 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11935>; Sun, 10 May 1992 16:18:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11938>; Sun, 10 May 1992 16:16:24 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sun, 10 May 1992 16:03:42 -0700
Received: from mail.uunet.ca ([142.77.1.1]) by alpha.xerox.com with SMTP id <11935>; Sun, 10 May 1992 16:03:16 PDT
Received: from ocunix by mail.uunet.ca with UUCP id <10290>; Sun, 10 May 1992 19:02:50 -0400
Received: by micor.OCUnix.On.Ca (smail2.5)
	id AA02601; 10 May 92 14:56:59 EDT (Sun)
Received: by sandelman.ocunix.on.ca id AA19348
  (5.65a/IDA-1.4.2 for moo-cows@parc.xerox.com); Sun, 10 May 92 14:48:41 -0400
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-NS-Transport-ID: 08002008D0FD001C8C11
In-Reply-to: "James Powell <jamesp@csn.org>
       \"<creeeeeek> the door opens a crack...\" (May  8,  7:20pm)Nilese"
Message-ID: <9205101848.AA19348@sandelman.ocunix.on.ca>
Date:	Sun, 10 May 1992 11:48:35 -0700
From:	mcr@latour.sandelman.ocunix.on.ca (Michael Richardson)
Sender: parc.xerox.com.PARC@xerox.com
To:	James Powell <jamesp@csn.org>, moo-cows@parc.xerox.com
Subject: Re: <creeeeeek> the door opens a crack...

On May 8,  7:20pm, James Powell wrote:
} I am indeed interested in a command level (shell and beyond) door.

  You say you need this for running newsreaders and error correcting
file transfer protocols --- I assume that you mean you want to drop
the player into rn, or sz, etc..  right? 
  You want an 8 bit clean connection --- do you need a pty in between,
or would a stream pipe with ldterm or ttcompat do the trick (do you
need /dev/tty in other words)... Hmm. I just realized I haven't a clue
how to *make* a stream pipe under SunOS or even if I can. socketpair()
isn't what I want. Onwards....

} Michael Richardson writes:
} >  A co-process might be created in a chroot'ed environment to act as a

} Mike Gallaher <mg@bds.bds.com> writes:
} >Write a program that logs into the moo as a player, and sits in
} >a room waiting for people to come in and say, for instance,
} >"ls", to which it would respond

  Neither of these give you want you want -- access from the external
program to the users' connection. I presume that they are either
logged in via terminal server to your `bbs' by modem and terminal
program, or they have some other mechanism to start a protocol on
their side. If they are logged into a Unix machine and telnet'ed to
the MOO, well: (t)rrn and ftp ;-) --- and run sz locally.
  I do not believe that there is a way to pass file descriptors
through sockets of any kind. (I'm hoping to be told that I'm wrong)
  This is definitely possible with stream devices, so it should be
reasonably trivial to post a special `read' on that users' socket
until the external program `returns' --- I think an independant
(possibly chroot'ed) process would be best here. 

  P.S. concerning server slow-down --- I'm noticing the occasional
iassoc()... task exceeded seconds too. I'm not entirely sure I
understand what iassoc() is doing that requires so much time though.
object in room/on player matching is not it I think.


-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca     Bell: (613) 237-5629
SCHOOL: 192228@physics.carleton.ca      




From morticia.cnns.unt.edu!cluther Mon May 11 07:39:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "11" "May" "1992" "07:33:48" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "19" "Re: <creeeeeek> the door opens a crack..." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 11 May 1992 07:39:34 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11575>; Mon, 11 May 1992 07:38:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11561>; Mon, 11 May 1992 07:36:27 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 11 May 1992 07:34:56 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11564>; Mon, 11 May 1992 07:34:25 PDT
Received: by morticia.cnns.unt.edu id AA20860
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Mon, 11 May 1992 09:33:50 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001C913A
In-Reply-to: "<9205101848.AA19348@sandelman.ocunix.on.ca>; from \"Michael Richardson\" at May 10, 92 11:48 am"
Message-ID: <199205111433.AA20860@morticia.cnns.unt.edu>
Date:	Mon, 11 May 1992 07:33:48 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	mcr@latour.sandelman.ocunix.on.ca (Michael Richardson)
cc:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Re: <creeeeeek> the door opens a crack...

Michael Richardson (>) writes:
> 
>   P.S. concerning server slow-down --- I'm noticing the occasional
> iassoc()... task exceeded seconds too. I'm not entirely sure I
> understand what iassoc() is doing that requires so much time though.
> object in room/on player matching is not it I think.

Pick up a copy of the GNoo server, which has assoc and iassoc built into the
server.  You will need to make a small change the the assoc and iassoc 
moo calls (that is, passing the @args to listassoc() and listiassoc() built-ins)
but, it's a simple fix, and you will notice a difference.

The GNoo server is ftp'able at morticia.cnns.unt.edu, /pub/mud.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From coyote.cs.wmich.edu!michaels Tue May 12 00:33:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "00:24:41" "-0700" "chris" "michaels@coyote.cs.wmich.edu " nil "23" "chown || quota ?" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Tue, 12 May 1992 00:33:26 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11526>; Tue, 12 May 1992 00:32:48 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11594>; Tue, 12 May 1992 00:29:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 12 May 1992 00:25:14 -0700
Received: from coyote.cs.wmich.edu ([141.218.40.40]) by alpha.xerox.com with SMTP id <11526>; Tue, 12 May 1992 00:24:55 PDT
Received: by coyote.cs.wmich.edu (4.1/SMI-4.1)
	id AA12693; Tue, 12 May 92 03:24:44 EDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD001C9FAA
Message-ID: <9205120724.AA12693@coyote.cs.wmich.edu>
Date:	Tue, 12 May 1992 00:24:41 -0700
From:	michaels@coyote.cs.wmich.edu (chris)
To:	moo-cows@parc.xerox.com
Subject: chown || quota ?


  Hi all!

    I have a question concerning a players quota and @chown.
    When I use @chown on an object either owned by myself
    or by a player, and transfer ownership to another player,
    should a quota change occur for the two players involved?

    An example would be...

    @create $thing named foo
    @chown foo Wizard   ( this is done as my player wizard named Bob )

    my quota allows me only to create 19 more objects without recycling
    since I no longer control that object, should it still be counted
    as part of my quota?  This is very trivial, but I wish to keep
    objects with wizard perms owned by Wizard, just to be consistant
    throughout the database.  I might be missing something....


    chris

    michaels@coyote.cs.wmich.edu

From cs.stanford.edu!crew Tue May 12 14:14:33 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "14:02:10" "-0700" "Roger Crew" "crew@cs.stanford.edu" nil "36" "Re: chown || quota ?" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 14:14:28 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11757>; Tue, 12 May 1992 14:13:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11745>; Tue, 12 May 1992 14:09:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 12 May 1992 14:02:41 -0700
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11745>; Tue, 12 May 1992 14:01:55 PDT
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA14505; Tue, 12 May 92 14:02:11 PDT
X-NS-Transport-ID: 08002008D0FD001CA9EE
In-Reply-to: "Your message of \"Tue, 12 May 92 00:24:41 PDT.\"
             <9205120724.AA12693@coyote.cs.wmich.edu>"
Message-ID: <9205122102.AA14505@Xenon.Stanford.EDU>
Date:	Tue, 12 May 1992 14:02:10 -0700
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: chown || quota ?

>       When I use @chown on an object either owned by myself
>       or by a player, and transfer ownership to another player,
>       should a quota change occur for the two players involved?

In fact, LambdaCore changed recently so that quota would indeed be
updated on a @chown --- this was essentially a matter of grepping for
all occurences of `.owner = ...' and replacing with $wiz_utils:set_owner(...),
the idea being that this routine would take care of quota adjustments
and also the .owned_objects property (implemented recently to make
@audit go faster).  $wiz_utils, in fact, has a number of routines that
are intended to be used in place of the corresponding server-builtin
constructs (notably, :set_player(foo) for set_player_flag(foo,1),
:unset_player(foo) for set_player_flag(foo,0), :set_programmer(foo)
for foo.programmer = 1, ...)

The idea behind the current quota system is that you get to own n objects,
whether you create them or have them chowned to you.  The question of 
increasing/decreasing one's quota is then handled separately.

>       my quota allows me only to create 19 more objects without recycling
>       since I no longer control that object, should it still be counted
>       as part of my quota?  

Indeed no, but in the previous LambdaCore, one had to update the quota
by hand.  Note that since your player Bob is himself a wizard, he
could easily do ;player.ownership_quota = 2147483647 which would take care
this particular problem for a long time to come.

Actually, what I'd like to see is to have the server handle
:initialize()/:recycle()/:chparent() correctly (more on this in an
upcoming posting --- yes, I have a number of these stacked up...) 
so that the quota system can be done entirely in-DB (what I have in mind
would incidentally allow having quota not apply to certain classes of
objects e.g., exits).

	Roger

From cs.stanford.edu!crew Tue May 12 14:30:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "14:20:47" "-0700" "Roger Crew" "crew@cs.stanford.edu" nil "45" "Re: Security 'n MOO 'n UNIX 'n stuff." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 14:30:14 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11791>; Tue, 12 May 1992 14:29:05 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11740>; Tue, 12 May 1992 14:26:53 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 12 May 1992 14:19:50 -0700
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11739>; Tue, 12 May 1992 14:19:15 PDT
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA15806; Tue, 12 May 92 14:20:47 PDT
X-NS-Transport-ID: 08002008D0FD001CAA79
Message-ID: <9205122120.AA15806@Xenon.Stanford.EDU>
Date:	Tue, 12 May 1992 14:20:47 -0700
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: Security 'n MOO 'n UNIX 'n stuff.

A quick remark about the allowing-system-commands-in-MOO debate:

The concerns for security should not be understated.  On LambdaMOO, despite
being fairly security conscious from the beginning, we've had, in the past few
months, no less than 3 instances of players successfully cracking themselves
wizard bits.  Granted, there were no instances in the previous year and a half
that I know of, but who knows?

I suppose, given the size and general hairiness of the full Lambda DB --- there
are somewhere around 800-1000 wizard-owned verbs (400-500 in LambdaCore itself)
--- and the number of players currently attacking it, that it was bound to
happen sooner or later.  But that only underscores the point.

BTW - of these instances, only one affects the LambdaCore distribution.
Details available as soon as those actually running such a beast in public
(is GodNet the only one? --- archwizardly types should send me email) 
get a chance to apply the patch.

Meanwhile, on an entirely different subject:

\begin{flame}

  Someone writes (for the nth time this month)
  >  please remove me from moo-cows....

  DAMMIT!  Use MOO-Cows-Request @parc.xerox.com
			^^^^^^^

  if you want to be taken off the list.  

  In fact, this convention holds for a large number of internet mailing lists;
  you would do well to learn it NOW so that you don't piss off people in the
  future.

\end{flame}

I really hated to do that, but the full list has been getting so many of these
lately, that I didn't really see any alternative.  Profuse apologies to those
of you who actually do know how to READ and understood this the first time
around...

--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

From csn.org!jamesp Tue May 12 18:33:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "18:24:08" "-0700" "James Powell" "jamesp@csn.org" "<199205130124.AA15504@teal.csn.org>" "75" "A loose framework for the UNIX gateway." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 18:33:25 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11998>; Tue, 12 May 1992 18:32:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11996>; Tue, 12 May 1992 18:30:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Tue, 12 May 1992 18:27:20 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11988>; Tue, 12 May 1992 18:26:48 PDT
Received: from teal.csn.org ([128.138.213.22]) by alpha.xerox.com with SMTP id <11995>; Tue, 12 May 1992 18:24:28 PDT
Received: by teal.csn.org id AA15504
  (5.65c/IDA-1.4.4 for MOO-Cows@Xerox.Com); Tue, 12 May 1992 19:24:08 -0600
X-NS-Transport-ID: 08002008D0FD001CAE70
Message-ID: <199205130124.AA15504@teal.csn.org>
Date:	Tue, 12 May 1992 18:24:08 -0700
From:	James Powell <jamesp@csn.org>
To:	moo-cows.parc@xerox.com
Subject: A loose framework for the UNIX gateway.


mcr@latour.sandelman.ocunix.on.ca (Michael Richardson) writes:

>On May 8,  7:20pm, James Powell wrote:
>} I am indeed interested in a command level (shell and beyond) door.
>
>  You say you need this for running newsreaders and error correcting
>file transfer protocols --- I assume that you mean you want to drop
>the player into rn, or sz, etc..  right? 

:nods.

>  You want an 8 bit clean connection --- do you need a pty in between,
>or would a stream pipe with ldterm or ttcompat do the trick (do you
>need /dev/tty in other words)... Hmm. I just realized I haven't a clue
>how to *make* a stream pipe under SunOS or even if I can. socketpair()
>isn't what I want. Onwards....

Having just discovered the Streams package, it is difficult for me to say
whether such a beast would work.  My understanding is that Streams is available
only on System V and System V derived UNIXi.  Is that correct?  If so, it
that would make a more generic solution more desirable. 

>} Michael Richardson writes:
>} Mike Gallaher <mg@bds.bds.com> writes:
>} >Write a program that logs into the moo as a player, and sits in
>} >a room waiting for people to come in and say, for instance,
>} >"ls", to which it would respond
>
>  Neither of these give you want you want -- access from the external
>program to the users' connection. I presume that they are either

I agree ... while they could interact with the user, they would not be suited
to the rigors of VT100 or ZMODEM.  How's this for a framework? Please excuse
any fuzziness, I'm still trying to grok that great twisted thang that is
UNIX networking.

User
  |
Telnet
  | <socketpair>
MOO Server
  | <socketpair>
Process Server
  | <inetd-constructed socketpair>
/dev/ptty
  | 
trn/sz

Roger Crew writes:
>A quick remark about the allowing-system-commands-in-MOO debate:
>
>The concerns for security should not be understated.  On LambdaMOO, despite
>being fairly security conscious from the beginning, we've had, in the past few
>months, no less than 3 instances of players successfully cracking themselves
>wizard bits.  Granted, there were no instances in the previous year and a half
>that I know of, but who knows?
>[...]
>BTW - of these instances, only one affects the LambdaCore distribution.
>Details available as soon as those actually running such a beast in public
>(is GodNet the only one? --- archwizardly types should send me email) 
>get a chance to apply the patch.

A sobering advisory. I did not mean to poo-poo the importance of security 
within MOO, but rather to discard it as a reason for not opening the UNIX 
gateway. Have the patches been applied to the LambdaCore distribution? 
More generally, is it possible to install new LambdaCore releases into extant 
DBs?
 
>Meanwhile, on an entirely different subject:
>
>\begin{flame}

Halleluja!
  -James-

From erika.bighouse.unipress.com!sparc!clay Tue May 12 18:39:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "17:51:10" "-0700" "John Clayton Webster" "sparc!clay@erika.bighouse.unipress.com " nil "49" "moosh (was: MOONIX)" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 18:39:56 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11988>; Tue, 12 May 1992 18:39:15 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11999>; Tue, 12 May 1992 18:37:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Tue, 12 May 1992 18:34:45 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11997>; Tue, 12 May 1992 18:33:52 PDT
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <11990>; Tue, 12 May 1992 18:18:55 PDT
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA05957; Tue, 12 May 92 21:18:45 EDT
Received: from erika.UUCP by repo.unipress.com (4.1/SMI-4.1/UniPress121291.1)
	id AA01451; Tue, 12 May 92 21:18:40 EDT via UUCP
Received: from sparc.bighouse by erika.bighouse.unipress.com (4.0/SMI-4.0)
	id AA24061; Tue, 12 May 92 20:44:49 EDT
Received: by sparc.bighouse (4.1/SMI-4.1)
	id AA18001; Tue, 12 May 92 20:51:10 EDT
X-NS-Transport-ID: 08002008D0FD001CAE58
Message-ID: <9205130051.AA18001@sparc.bighouse>
Date:	Tue, 12 May 1992 17:51:10 -0700
From:	sparc!clay@erika.bighouse.unipress.com (John Clayton Webster)
To:	moo-cows.parc@xerox.com
Subject: moosh (was: MOONIX)


>> Has anyone hacked (or thought about hacking) a doorway through which UNIX
>> applications might run?
>>   -James-

> I'm sure Pavel has thought of this, around about three o'clock in the
> morning, just before he wakes up screaming in a cold sweat.  What's the
> application, though?  I can imagine it's a very general purpose change that
> will tend to accumulate applications with time, but it seems odd to me that
> nobody has mentioned what it would be used for.  Knowing what the legitimate
> applications were would surely ease the security issues debate, once the
> Clay-Pavel flamewar has died down.

What could it be used for?  What applications to run?

This is an old idea I (and probably many others) came up with around, as you
said, three am.

You want lots of freedom.
They want decent security.

What everyone wants when everyone is done bargaining is some sort of
shell... leaving MOO just a shell of what it once was.  So why not just take
that leap?

Comeon -- just partition a disk, make a moo shell (do a hell of
re/de-coding).  Yeah, from scratch.  Give the "players" accounts with moosh
as their shell, limited group permissions and you're off. 

Distributed moosh hosts?  Like those tcp commands?  I knew a guy hacking
mud-flavor into ftp.  Get the idea?  Use any of the UNIX "macintosh-feel"
desktop apps as a guide for the concept of a room.  Drive it with a
user-expandable Natural Language to handle the all those inanimate objects.

Like everything disk-based?  Good, you're in luck.  Got any virtual pages?
Sure you do!

Having a semester of os dsgn/implem let me feel how un-fun it would be to
handle the communication...  so whala -- zilch.  'though it wouldn't be
*that* much worse (pain-percentage-wise) than doing threaded procs.

In the end, you'd be left with an OOSH for normal UNIX.  Would it be any
easier ('tho' obviously less <echem> "portable") to start from an OOOS?
Anyone with experience?


-- Clay Webster (clay@unipress.com)
   SirRiel


From morticia.cnns.unt.edu!cluther Tue May 12 19:47:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "19:40:43" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "17" "Re: A loose framework for the UNIX gateway." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 19:47:44 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12020>; Tue, 12 May 1992 19:46:53 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12016>; Tue, 12 May 1992 19:45:22 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Tue, 12 May 1992 19:42:10 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12014>; Tue, 12 May 1992 19:41:32 PDT
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12016>; Tue, 12 May 1992 19:40:57 PDT
Received: by morticia.cnns.unt.edu id AA28179
  (5.65c/IDA-1.4.4 for moo-cows.parc@xerox.com); Tue, 12 May 1992 21:40:43 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001CAF31
In-Reply-to: "<199205130124.AA15504@teal.csn.org>; from \"James Powell\" at May 12, 92 6:24 pm
	As a st"
Message-ID: <199205130240.AA28179@morticia.cnns.unt.edu>
Date:	Tue, 12 May 1992 19:40:43 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	jamesp@csn.org (James Powell)
cc:	moo-cows.parc@xerox.com
Subject: Re: A loose framework for the UNIX gateway.

James Powell (>) writes:

> Having just discovered the Streams package, it is difficult for me to say
> whether such a beast would work.  My understanding is that Streams is available
> only on System V and System V derived UNIXi.  Is that correct?  If so, it
> that would make a more generic solution more desirable. 

I could not help but find this comment borderline amusing.  I hadn't realized
that System V was not generic.

Now, back to moochat...

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

From ecsuc.ctstateu.edu!PLUMMERS Tue May 12 20:02:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "19:59:11" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "6" "remember" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 20:02:15 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12018>; Tue, 12 May 1992 20:01:56 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12019>; Tue, 12 May 1992 20:00:24 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Tue, 12 May 1992 19:57:58 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12017>; Tue, 12 May 1992 19:57:34 PDT
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <12014>; Tue, 12 May 1992 19:57:03 PDT
X-Vmsmail-To: SMTP%"moo-cows.parc@xerox.com"
X-NS-Transport-ID: 08002008D0FD001CAF52
Message-ID: <920512225911.2021930f@ECSUC.CTSTATEU.EDU>
Date:	Tue, 12 May 1992 19:59:11 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	moo-cows.parc@xerox.com
Subject: remember


     I just wanted to remind everyone that NOT EVERTONE is on a Unix...I am
using a VAX.


    				Saruman

From ee.ualberta.ca!daum Tue May 12 21:12:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "12" "May" "1992" "21:05:07" "-0700" "Tanya Louise Daum" "daum@ee.ualberta.ca" nil "15" "Re: A loose framework for the UNIX gateway." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 12 May 1992 21:12:49 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12027>; Tue, 12 May 1992 21:11:20 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12023>; Tue, 12 May 1992 21:09:32 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Tue, 12 May 1992 21:06:22 -0700
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <12021>; Tue, 12 May 1992 21:05:51 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA22503; Tue, 12 May 92 22:05:10 -0600
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD001CAFE4
In-Reply-to: "<199205130240.AA28179@morticia.cnns.unt.edu>; from \"Clay Luther\" at May 12, 92 7:40 pm--------"
Message-ID: <92May12.210551pdt.12021@alpha.xerox.com>
Date:	Tue, 12 May 1992 21:05:07 -0700
From:	Tanya Louise Daum <daum@ee.ualberta.ca>
To:	MOO-Cows@parc.xerox.com
Subject: Re: A loose framework for the UNIX gateway.

> 
> I could not help but find this comment borderline amusing.  I hadn't realized
> that System V was not generic.

	And trust you, in your infinite wisdom to point it out to us *all*
> 
> Now, back to moochat...
> 
	Yes, please, back to moochat, and enough of your infantile attacks on
everyone you've decided to think is inferior to you.

	Opiate@LambdaMOO 	BigBrother@Airstrip One
	-----------------------------------------------



From doc.imperial.ac.uk!mjb Wed May 13 06:05:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "13" "May" "1992" "05:52:02" "-0700" "Matthew Jude Brown" "mjb@doc.imperial.ac.uk" nil "13" "Re: A loose framework for the UNIX gateway." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 13 May 1992 06:05:15 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11926>; Wed, 13 May 1992 06:04:40 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11917>; Wed, 13 May 1992 06:01:31 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Wed, 13 May 1992 05:53:53 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11908>; Wed, 13 May 1992 05:53:35 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11908>; Wed, 13 May 1992 05:53:06 PDT
Via: doc.imperial.ac.uk; Wed, 13 May 1992 13:52:12 +0100
Via: uk.ac.ic.doc ; 13 May 92 13:52 BST
X-Mailer: Mail User's Shell (7.0.3 12/22/89)
X-NS-Transport-ID: 08002008D0FD001CB2F6
Message-ID: <9205131352.aa28867@puffin.doc.ic.ac.uk>
Date:	Wed, 13 May 1992 05:52:02 -0700
From:	Matthew Jude Brown <mjb@doc.imperial.ac.uk>
To:	Clay Luther <cluther@morticia.cnns.unt.edu>,
	James Powell <jamesp@csn.org>
cc:	moo-cows.parc@xerox.com
Subject: Re: A loose framework for the UNIX gateway.

Clay Luther <cluther@morticia.cnns.unt.edu> writes:
>I hadn't realized that System V was not generic.

Depends which sect of the UNIX religion you follow - BSD or SYSV :)

More to the point, MOO is IMHO friendlier to BSD, though the major
differences between the two are rapidly disappearing.

-- 
| Matthew J. Brown | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk | Imperial College,  | lectures He wouldn't have created |
| Morven on Lambda | 180 Queen's Gate   | double-sided photocopiers.        |
|__________________| LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

From parc.xerox.com!pavel Wed May 13 09:36:13 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "13" "May" "1992" "09:22:03" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "10" "Re: A loose framework for the UNIX gateway." "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 13 May 1992 09:36:11 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12047>; Wed, 13 May 1992 09:34:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12012>; Wed, 13 May 1992 09:31:20 PDT
Received: by lambda.parc.xerox.com id <58371>; Wed, 13 May 1992 09:22:04 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD001CB5EA
In-Reply-to: <199205130124.AA15504@teal.csn.org>
Message-ID: <92May13.092204pdt.58371@lambda.parc.xerox.com>
References: <199205130124.AA15504@teal.csn.org>
Date:	Wed, 13 May 1992 09:22:03 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	jamesp@csn.org, MOO-Cows@parc.xerox.com
Subject: Re: A loose framework for the UNIX gateway.

   Have the patches been applied to the LambdaCore distribution? 

Not yet.  I will see if I can instead produce a new Core DB sometime today.

   More generally, is it possible to install new LambdaCore releases into
   extant DBs?

Not with existing technology.

	Pavel

From cheetah.math.oxy.edu!t_pascal Thu Jun  4 12:54:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "4" "June" "1992" "12:42:30" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "41" "Free codes..." "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 4 Jun 1992 12:54:32 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11662>; Thu, 4 Jun 1992 12:52:21 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11663>; Thu, 4 Jun 1992 12:49:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 4 Jun 1992 12:47:00 -0700
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <11670>; Thu, 4 Jun 1992 12:46:15 PDT
Received: from jaguar.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA02389; Thu, 4 Jun 92 12:42:32 PDT
Received: by jaguar.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01492; Thu, 4 Jun 92 12:42:30 PDT
Received: by NeXT Mailer (1.63)
X-NS-Transport-ID: 08002008D0FD001DD60F
Message-ID: <9206041942.AA02389@cheetah.math.oxy.edu>
Date:	Thu, 4 Jun 1992 12:42:30 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	moo-cows@parc.xerox.com
Subject: Free codes...



Hello all.  I am interested in finding good code for
my moo.  I know there is the LambdaCore database, but
I wish people could make other databases available for
ftp.

My idea is that we could have a sources ftp site, where
one could grab sources for fun objects:  For example,
I have a phone object, an elevator, etc, etc.  I think
it would spread the one true MUD more widely if people
knew they could get one up and have neat, fun stuff to
add at will...  Just like computers, the MOO would
be more popular if there were more "software" for it.

I would love it if I could ftp code for a bbs, or code
for command aliases like those found on GodNet.  I
wonder if we could make a "script" language, and make
a standard makefile for the code, so that one would
ftp the sources, cut and paste, and the script would
make all the verbs, properties and objects, etc, etc.

Are there already ftp sites for moo code?  Is anyone
interested in the above ideas?  I would be the first
to put my meagre moo sources available for free.  (of
course, there would be the usual honor code as regards
any creative efforts accomplished by a person)

---

---------
T. Pascal, King of Pascal          | "He travels  
fastest who travels alone,
1600 Campus Road, Box 829          | but not when the  
frost drops below zero
Los Angeles, CA 90041              | fifty degrees or  
more."
                                   |         -Old  
eskimo saying
...!gate.oxy.edu!t_pascal  
t_pascal@{cub.math,jaguar.math,bobcat,tiger}.oxy.edu

From lucid.com!yduj Thu Jun  4 14:00:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "4" "June" "1992" "13:55:03" "-0700" "Judy Anderson" "yduj@lucid.com" nil "12" "Free codes..." "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 4 Jun 1992 14:00:50 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11637>; Thu, 4 Jun 1992 14:00:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11636>; Thu, 4 Jun 1992 13:57:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Thu, 4 Jun 1992 13:52:56 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11613>; Thu, 4 Jun 1992 13:52:41 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA01615g; Thu, 4 Jun 92 13:44:25 PDT
Received: by boston-harbor id AA16592g; Thu, 4 Jun 92 16:55:03 EDT
X-NS-Transport-ID: 08002008D0FD001DD79C
In-Reply-to: "t_pascal@cheetah.math.oxy.edu's message of Thu, 4 Jun 1992 12:42:30 PDT <9206041942.AA02389@cheetah.math.oxy.edu>"
Message-ID: <9206042055.AA16592@boston-harbor>
Date:	Thu, 4 Jun 1992 13:55:03 -0700
From:	Judy Anderson <yduj@lucid.com>
To:	t_pascal@cheetah.math.oxy.edu
cc:	moo-cows@parc.xerox.com
Subject: Free codes...

Interesting idea.  I was all set to tromp on it, on the grounds that
it irks me to have copies of things from one mud to another...  For
example, I wouldn't want to see a copy of the lambdamoo hot tub appear
on another MOO.  But a lot of the code on LambdaMOO is pretty generic.
Like, generic furniture.  Maybe I'll make a minor project to @dump my
various generics to go on such an FTP site.  Indeed, might it be
reasonable to use parcftp:/pub/MOO/contrib/ for this purpose?  Just
name the files whatever.moocode...

Judy Anderson yclept yduJ     yduJ@lucid.com    'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu


From casbah.acns.nwu.edu!hpa Thu Jun  4 14:35:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "4" "June" "1992" "14:28:42" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "26" "Re: Free codes..." "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 4 Jun 1992 14:35:22 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11665>; Thu, 4 Jun 1992 14:34:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11637>; Thu, 4 Jun 1992 14:32:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 4 Jun 1992 14:29:02 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11613>; Thu, 4 Jun 1992 14:28:46 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA29776; Thu, 4 Jun 92 16:28:43 CDT
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001DD849
Message-ID: <9206042128.AA29776@casbah.acns.nwu.edu>
Date:	Thu, 4 Jun 1992 14:28:42 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: Re: Free codes...
Reply-to: hpa@nwu.edu

> Interesting idea.  I was all set to tromp on it, on the grounds that
> it irks me to have copies of things from one mud to another...  For
> example, I wouldn't want to see a copy of the lambdamoo hot tub appear
> on another MOO.  But a lot of the code on LambdaMOO is pretty generic.
> Like, generic furniture.  Maybe I'll make a minor project to @dump my
> various generics to go on such an FTP site.  Indeed, might it be
> reasonable to use parcftp:/pub/MOO/contrib/ for this purpose?  Just
> name the files whatever.moocode...

The main question I have about this relates to the nature of MOOs in
general; due to the object-oriented nature of the system it becomes
necessary to recognize dependencies and document them.  Even if LambdaCore
can be assumed to be a common denominator, there are a lot of extensions
that are site-specific.

Still, I don't see why not to spread good ideas around.  After all, the
amazing programmability of MOOs is after all the main reason to use it...

	/hpa

-- 
INTERNET: hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:   HPA@NUACC     HAM RADIO: N9ITP, SM4TKN
IRC:      Scalar        NeXTMAIL:  hpa@lenny.acns.nwu.edu
"That dreemless sleep that cures all aches."


From williams.edu!94eco Thu Jun  4 15:10:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "4" "June" "1992" "15:04:15" "-0700" "Erik Ostrom" "94eco@williams.edu" nil "30" "RE: Free codes..." "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 4 Jun 1992 15:10:55 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11674>; Thu, 4 Jun 1992 15:10:30 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11677>; Thu, 4 Jun 1992 15:08:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 4 Jun 1992 15:05:01 -0700
Received: from rowe.williams.edu ([137.165.4.20]) by alpha.xerox.com with SMTP id <11658>; Thu, 4 Jun 1992 15:04:45 PDT
Received: from bigbird.cc.williams.edu by rowe.williams.edu with SMTP id AA16236
  (5.65c+/IDA-1.4.4 for <moo-cows@parc.xerox.com>); Thu, 4 Jun 1992 18:04:17 -0400
Received: by bigbird.cc.williams.edu (4.1/client-1.3)
	id AA02317; Thu, 4 Jun 92 18:04:15 EDT
X-NS-Transport-ID: 08002008D0FD001DD91E
In-Reply-to: "Judy Anderson's message of Thu, 4 Jun 1992 13:55:03 PDT <9206042055.AA16592@boston-harbor>"
Message-ID: <9206042204.AA02317@bigbird.cc.williams.edu>
Date:	Thu, 4 Jun 1992 15:04:15 -0700
From:	Erik Ostrom <94eco@williams.edu>
To:	moo-cows@parc.xerox.com
Subject: RE: Free codes...

> various generics to go on such an FTP site.  Indeed, might it be
> reasonable to use parcftp:/pub/MOO/contrib/ for this purpose?  Just
> name the files whatever.moocode...

Sounds smart to me.  I'd rather have a subdirectory of contrib for it
than just put everything in contrib, though.  Perhaps subdirectories
of that for large systems, if there are any.  Also, I'd prefer a
shorted filename extension: Are there any objections to .moo?

WRT compatibility between MOOs: Yes, it might be a good idea to
document dependencies.  In general objects can be written so the
dependencies are contained in a few properties.  (E.G., code that
wants to know if an object is a descendant of the generic puppet
should check $object_utils:isa(what, this.puppet).)  If this is the
only kind of distinction, objects can be ported just by changing the
values of a few properties.  In fact, I think #404:backup does
something like this.

Even if things can't be worked out that simply, though, converting MOO-code
from one database to another should not be all that hard; in porting
stuff from LambdaMOO to Distortion, I generally felt that if the
LambdaCode called for something we didn't have, either we had something
just as good with a different name, or the thing we were missing was
worth porting anyway.

I think the best method for documenting dependencies depends on what
format people want to use for the source placed on parcftp.  More on
that later, unless a de facto standard pops up before then.

--Erik/JoeFeedback

From lucid.com!yduj Thu Jun  4 15:43:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "4" "June" "1992" "15:39:58" "-0700" "Judy Anderson" "yduj@lucid.com" nil "7" "Free codes..." "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 4 Jun 1992 15:43:27 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11694>; Thu, 4 Jun 1992 15:42:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11680>; Thu, 4 Jun 1992 15:40:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Thu, 4 Jun 1992 15:37:57 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11665>; Thu, 4 Jun 1992 15:37:36 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA02149g; Thu, 4 Jun 92 15:29:21 PDT
Received: by boston-harbor id AA16946g; Thu, 4 Jun 92 18:39:58 EDT
X-NS-Transport-ID: 08002008D0FD001DD979
In-Reply-to: "Erik Ostrom's message of Thu, 4 Jun 1992 15:04:15 PDT <9206042204.AA02317@bigbird.cc.williams.edu>"
Message-ID: <9206042239.AA16946@boston-harbor>
Date:	Thu, 4 Jun 1992 15:39:58 -0700
From:	Judy Anderson <yduj@lucid.com>
To:	94eco@williams.edu
cc:	moo-cows@parc.xerox.com
Subject: Free codes...

Well, I decided I liked this idea so much I just upped and made a
directory on parcftp.

pub/MOO/contrib/moocode/

Currently empty.
						yduJ

From cheetah.math.oxy.edu!t_pascal Mon Jun  8 20:58:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "8" "June" "1992" "20:47:26" "-0700" "C. Regis Wilson" "t_pascal@cheetah.math.oxy.edu " nil "53" "MooCode" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 8 Jun 1992 20:58:40 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11672>; Mon, 8 Jun 1992 20:57:32 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11671>; Mon, 8 Jun 1992 20:54:39 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 8 Jun 1992 20:51:55 -0700
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <11662>; Mon, 8 Jun 1992 20:51:29 PDT
Received: by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA03835; Mon, 8 Jun 92 20:47:26 PDT
Received: by NeXT Mailer (1.63)
X-NS-Transport-ID: 08002008D0FD001E075C
Message-ID: <9206090347.AA03835@cheetah.math.oxy.edu>
Date:	Mon, 8 Jun 1992 20:47:26 -0700
From:	t_pascal@cheetah.math.oxy.edu (C. Regis Wilson)
To:	moo-cows@parc.xerox.com
Subject: MooCode


I put some moo code I had fixed up on the ftp site.
The code is free, and you can do whatever you please
with it.  Most is self explanatory, except the
"scheduler.moo"

Scheduler is a generic process scheduler which queues
events which should run infrequently (every hour, day,
etc.)  It only uses one process, and if there are no
tasks, it uses none.  The call is made through the
entry point "schedule".  The parameters are as follows:

number of seconds from now to execute
object number which has the verb you will run
verb name, as a string
arguments, as a list

For example, to schedule an announce in the player's
room in two hours, call thusly:

$scheduler:schedule(7200,player.location,"announce_all" 
,{player.name," farts."});

(please excuse my choice of example....:)

Things which need to be done in a cron tab like manner,
for instance, ever hour, every day, should schedule  
themselves,
run and re-schudule themselves, if necessary,  
recursively.

When you look at the scheduler, it will tell you the
jobs queued, etc.  Typing "reset scheduler", when in  
the
same room as it, will reset the box, if things get  
screwed.
Send me a note if you have problems, or get bugs.

Thanks,

---

---------
T. Pascal, King of Pascal          | "He travels  
fastest who travels alone,
1600 Campus Road, Box 829          | but not when the  
frost drops below zero
Los Angeles, CA 90041              | fifty degrees or  
more."
                                   |         -Old  
eskimo saying
...!gate.oxy.edu!t_pascal  
t_pascal@{cub.math,jaguar.math,bobcat,tiger}.oxy.edu

From ee.ualberta.ca!daum Mon Jun  8 22:28:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "8" "June" "1992" "22:22:23" "-0700" "Tanya Louise Daum" "daum@ee.ualberta.ca" nil "11" "Airstrip One Meeting Tuesday 7:00PM MDT" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 8 Jun 1992 22:28:29 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11678>; Mon, 8 Jun 1992 22:27:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11685>; Mon, 8 Jun 1992 22:24:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 8 Jun 1992 22:23:35 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11687>; Mon, 8 Jun 1992 22:23:08 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11672>; Mon, 8 Jun 1992 22:22:41 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA19179; Mon, 8 Jun 92 23:22:24 -0600
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD001E07E6
Message-ID: <92Jun8.222241pdt.11672@alpha.xerox.com>
Date:	Mon, 8 Jun 1992 22:22:23 -0700
From:	Tanya Louise Daum <daum@ee.ualberta.ca>
To:	Moo-cows.PARC@xerox.com
Subject: Airstrip One Meeting Tuesday 7:00PM MDT

For those of you interested in building and/or programming on an RPG MOO
loosely based (and horribly massacred) on George Orwell's "Ninety-Eighty-Four",
the MOO is holding a public meeting tomorrow at:

	7:00pm Mountain Daylight Time
	eigen.ee.ualberta.ca 1984

Feel free to create a new character for yourself, as we only have the one Guest
character installed.

Hope to see you there!

From lucid.com!oakland-hills!yduj Tue Jun 30 16:51:45 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "30" "June" "1992" "16:45:34" "-0700" "Judy Anderson" "yduj%oakland-hills@lucid.com " nil "9" "Wierdness in the server" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 30 Jun 1992 16:51:35 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12255>; Tue, 30 Jun 1992 16:50:53 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12265>; Tue, 30 Jun 1992 16:48:55 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 30 Jun 1992 16:47:03 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <12252>; Tue, 30 Jun 1992 16:46:53 PDT
Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA18113g; Tue, 30 Jun 92 16:37:46 PDT
Received: by oakland-hills.lucid (4.1/SMI-4.1)
	id AA05111; Tue, 30 Jun 92 16:45:34 PDT
X-NS-Transport-ID: 08002008D0FD001F32CE
In-Reply-to: "Clay Luther's message of Tue, 30 Jun 1992 16:08:48 PDT <199206302308.AA02329@morticia.cnns.unt.edu>"
Message-ID: <9206302345.AA05111@oakland-hills.lucid>
Date:	Tue, 30 Jun 1992 16:45:34 -0700
From:	yduj%oakland-hills@lucid.com (Judy Anderson)
To:	cluther@morticia.cnns.unt.edu
cc:	moo-cows@parc.xerox.com
Subject: Wierdness in the server

The idea behind logging of commands is to aid in determining the
immediate cause of a crash.  The list is only printed out during a
panic dump, and is not saved in the DB.  Since there are forked tasks
involved, you can't be sure that the last command typed was actually
the cause of the panic, but in some cases it is, so this can be a
help. 

Judy Anderson yclept yduJ   yduJ@symbolics.com  'yduJ' rhymes with 'fudge'
   Join the League for Programming Freedom, league@prep.ai.mit.edu

From morticia.cnns.unt.edu!cluther Tue Jun 30 17:05:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "30" "June" "1992" "16:08:48" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "21" "Wierdness in the server" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 30 Jun 1992 17:05:37 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12262>; Tue, 30 Jun 1992 17:05:02 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12249>; Tue, 30 Jun 1992 16:11:40 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 30 Jun 1992 16:09:24 -0700
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <12251>; Tue, 30 Jun 1992 16:08:50 PDT
Received: by morticia.cnns.unt.edu id AA02329
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Tue, 30 Jun 1992 18:08:48 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD001F3244
Message-ID: <199206302308.AA02329@morticia.cnns.unt.edu>
Date:	Tue, 30 Jun 1992 16:08:48 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows@parc.xerox.com (Moo Cows)
Subject: Wierdness in the server

Why/how are player commands being logged to the log file?

Jun 30 09:15:27: #4681: logon
Jun 30 09:15:32: #4681: n
Jun 30 09:15:47: #4681: l vidicamera
Jun 30 09:15:54: #4681: l bench
Jun 30 09:16:01: #4681: w
Jun 30 09:16:05: #4681: w
Jun 30 09:16:11: #4681: e
Jun 30 09:16:11: #4681: e
Jun 30 09:16:17: #4681: stats
Jun 30 09:16:18: PANIC-DUMPING on GN.db.new.PANIC ...

I have noticed that the logging only occurs within 15 minutes of a PANIC by
the server, so I'd like to turn it off.

-- 
Clay W. Luther                  cluther@morticia.cnns.unt.edu
Macintosh/Unix Programmer for Vortech Data, Inc.
Virtual System Consultant for the UNT Center for Network Neuroscience
(214) 994-1377

From xerox.com!parc.xerox.com.PARC Fri Jul  3 02:06:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "3" "July" "1992" "08:57:29" "-0700" "tim" "K317370%EDVZ.UNI-Linz.AC.AT@aearn.edvz.uni-linz.ac.at" nil "8" "How big is a MOO?" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Fri, 3 Jul 1992 02:06:09 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11741>; Fri, 3 Jul 1992 02:05:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11738>; Fri, 3 Jul 1992 02:02:24 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 3 Jul 1992 02:00:34 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11736>; Fri, 3 Jul 1992 02:00:16 PDT
Received: from AEARN.EDVZ.UNI-Linz.AC.AT ([140.78.2.1]) by alpha.xerox.com with SMTP id <11736>; Fri, 3 Jul 1992 01:59:54 PDT
Received: from ALIJKU11.EDVZ.Uni-Linz.AC.AT by AEARN.EDVZ.UNI-Linz.AC.AT (IBM VM SMTP R1.2.2MX) with BSMTP id 6866; Fri, 03 Jul 92 10:59:44 CDT
Received: from EDVZ.UNI-Linz.AC.AT (K317370@ALIJKU11) by
 ALIJKU11.EDVZ.Uni-Linz.AC.AT (Mailer R2.07) with BSMTP id 0254; Fri, 03 Jul 92
 10:59:42 CDT
XNS-Originator: <@aearn.edvz.uni-linz.ac.at:K317370@ALIJKU11.BITNET>
X-NS-Transport-ID: 08002008D0FD001F55AD
XNS-Originator: parc.xerox.com.PARC@Xerox.com
Errors-to: parc.xerox.com.PARC@xerox.com
Message-ID: <92Jul3.015954pdt.11736@alpha.xerox.com>
Date:	Fri, 3 Jul 1992 08:57:29 -0700
From:	tim <K317370%EDVZ.UNI-Linz.AC.AT@aearn.edvz.uni-linz.ac.at>
Sender: K317370%ALIJKU11@aearn.edvz.uni-linz.ac.at
To:	MOO <moo-cows@xerox.com>
Subject: How big is a MOO?


Well, the title says it all. If i was to install a MOO
somewhere, how much space would I need? It would probably
be quite small, and I am afraid not public at the moment,
but more for experimenting. Or have i misunderstood things
and MOO is rather private to xerox?

Tim

From lucid.com!oakland-hills!yduj Fri Jul  3 08:14:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "3" "July" "1992" "08:08:40" "-0700" "Judy Anderson" "yduj%oakland-hills@lucid.com " nil "20" "How big is a MOO?" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Fri, 3 Jul 1992 08:14:40 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11765>; Fri, 3 Jul 1992 08:13:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11766>; Fri, 3 Jul 1992 08:12:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 3 Jul 1992 08:11:01 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11764>; Fri, 3 Jul 1992 08:10:37 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11764>; Fri, 3 Jul 1992 08:10:02 PDT
Received: from oakland-hills.lucid ([192.31.212.153]) by heavens-gate.lucid.com id AA26209g; Fri, 3 Jul 92 08:00:47 PDT
Received: by oakland-hills.lucid (4.1/SMI-4.1)
	id AA06839; Fri, 3 Jul 92 08:08:40 PDT
Illegal-Object: Syntax error in To: address found on alpha.xerox.com:
	To:	K317370%EDVZ.UNI-Linz.AC.@aearn.edvz.uni-linz.ac.at
					 ^-illegal word in localpart
X-NS-Transport-ID: 08002008D0FD001F5742
In-Reply-to: "tim's message of Fri, 3 Jul 1992 08:57:29 PDT <92Jul3.015954pdt.11736@alpha.xerox.com>"
Message-ID: <9207031508.AA06839@oakland-hills.lucid>
Date:	Fri, 3 Jul 1992 08:08:40 -0700
From:	yduj%oakland-hills@lucid.com (Judy Anderson)
To:	moo-cows.PARC@xerox.com
cc:	moo-cows.PARC@xerox.com
Subject: How big is a MOO?

The DB for a moo using the "core" database starts at 400kbytes.  The
LambdaMOO DB is currently about 45mbytes.  I ran a private moo using
its own core DB (that means starting from scratch, about 1kbyte db and
*no* funtionality; amusing, but IMHO not very useful), the DB file
grew to about 100K.  But it was private, only four programmers
actually working on it and eight users total, and most of the time not
a lot of work actually happened.

The program itself I think weighs in about half a meg, plus you need
room for all the sources and .o files.  I wouldn't try running even a
private MOO without at least two or three meg available.

MOO is definitely public, just FTP it off of parcftp.xerox.com:/pub/MOO.

I don't know how much space the program consumes in terms of memory;
probably a lot.  I didn't have a problem on a sun3 that wasn't really
doing much else besides mail and file server for a small site, but
then my MOO was really small.
						yduJ


From cheetah.math.oxy.edu!t_pascal Tue Jul  7 21:22:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "7" "July" "1992" "21:07:48" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "23" "New $scheduler!!" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 7 Jul 1992 21:22:14 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12045>; Tue, 7 Jul 1992 21:21:16 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12049>; Tue, 7 Jul 1992 21:18:10 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 7 Jul 1992 21:15:18 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12044>; Tue, 7 Jul 1992 21:14:54 PDT
Received: from beta.xerox.com ([13.1.64.94]) by alpha.xerox.com with SMTP id <12046>; Tue, 7 Jul 1992 21:14:10 PDT
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by beta.xerox.com with SMTP id <7300>; Tue, 7 Jul 1992 21:13:59 -0700
Received: from jaguar.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA05506; Tue, 7 Jul 92 21:07:48 PDT
Received: by jaguar.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04103; Tue, 7 Jul 92 21:07:48 PDT
X-NS-Transport-ID: 08002008D0FD001F83CD
Message-ID: <9207080407.AA05506@cheetah.math.oxy.edu>
Date:	Tue, 7 Jul 1992 21:07:48 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	moo-cows@beta.xerox.com
Subject: New $scheduler!!


Of course, I had to release a new version of $scheduler, and of
course it is twenty times as complicated and a hundred times as
long as the first version :)

Anyway, if you don't know what $scheduler is, grab the file
from beta (in the moocode directory), and read the last section.
It describes all the stuff you need to know, pretty much.

For those who had the original, here are the additions, thanks
to Chaos of GodNet and FoodPlain!!!

1) ability to schedule tasks every so often, automagically.
2) a way to specify "pseudo-task id"s and kill jobs on the scheduler.
3) I forget.  But it's nice stuff, I'm too tired to elaborate.

(My NeXT serever crashed, my MOO is down, I lost 2 weeks of
database, I can't read my mail, I can't read news, I can't cut
and paste, and my .sig is gone!!!!)

But life is good, none-the-less.

Enjoy.

From matt.ksu.ksu.edu!lyn Sat Jul 11 17:02:01 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "11" "July" "1992" "16:49:14" "-0700" "Myself" "lyn@matt.ksu.ksu.edu " nil "9" "Help with DOS MOO" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 11 Jul 1992 17:01:53 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11951>; Sat, 11 Jul 1992 17:01:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11953>; Sat, 11 Jul 1992 16:55:35 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 11 Jul 1992 16:50:22 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11951>; Sat, 11 Jul 1992 16:50:03 PDT
Received: from matt.ksu.ksu.edu ([129.130.12.2]) by alpha.xerox.com with SMTP id <11951>; Sat, 11 Jul 1992 16:49:18 PDT
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA01683; Sat, 11 Jul 92 18:49:15 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD001FC375
Message-ID: <9207112349.AA01683@matt.ksu.ksu.edu>
Date:	Sat, 11 Jul 1992 16:49:14 -0700
From:	lyn@matt.ksu.ksu.edu (Myself)
To:	MOO-Cows.PARC@xerox.com
Subject: Help with DOS MOO

  Is there a kind soul out there who can give me some help with the
MS-DOS port of Lambda-MOO? I have an interest in it, but I have not
been able to do much, as I could not find any sort of documentation
that had the info I need. More details upon interest shown.

Thanks, Myself (lyn@matt.ksu.ksu.edu)
a.k.a. havas (Lambda)
	loki (floodplain)
	vorn (the Underdark)

From matt.ksu.ksu.edu!edwanji Sun Jul 12 13:43:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "12" "July" "1992" "13:34:41" "-0700" "Edwanji Lemorian" "edwanji@matt.ksu.ksu.edu " nil "12" "Lambda-MOO server question" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 12 Jul 1992 13:43:17 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11995>; Sun, 12 Jul 1992 13:42:56 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12000>; Sun, 12 Jul 1992 13:40:17 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 12 Jul 1992 13:35:45 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11995>; Sun, 12 Jul 1992 13:35:16 PDT
Received: from matt.ksu.ksu.edu ([129.130.12.2]) by alpha.xerox.com with SMTP id <11995>; Sun, 12 Jul 1992 13:34:44 PDT
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA23141; Sun, 12 Jul 92 15:34:42 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD001FC825
Message-ID: <9207122034.AA23141@matt.ksu.ksu.edu>
Date:	Sun, 12 Jul 1992 13:34:41 -0700
From:	edwanji@matt.ksu.ksu.edu (Edwanji Lemorian)
To:	MOO-Cows.PARC@xerox.com
Subject: Lambda-MOO server question

In the documentation for the MOO server, it state that it would be simple
to write a networking module that would just 'pretend' to network. This
would allow single-user operation on the data-base without ocupying a port
or opening up for other people who could possible break in and interupt
work.
I was wondering if anyone out there had writen such a module and how I
could get hold of it. (I'd write it myself, but i havn't gotten around to
learing C)
Thanks for any help.

-- Edwanji Lemorian, edwanji@matt.ksu.ksu.edu
   aka Eddie

From senex.unh.edu!unhtel!morwyn!root Sun Jul 12 14:11:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "12" "July" "1992" "14:59:08" "-0700" "System Administrator" "root@morwyn.uucp" nil "28" "Lambda-MOO server question" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 12 Jul 1992 14:11:03 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12009>; Sun, 12 Jul 1992 14:10:18 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12006>; Sun, 12 Jul 1992 14:08:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Sun, 12 Jul 1992 14:04:21 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12002>; Sun, 12 Jul 1992 14:03:57 PDT
Received: from senex.unh.edu ([132.177.128.103]) by alpha.xerox.com with SMTP id <12004>; Sun, 12 Jul 1992 14:03:12 PDT
Received: by senex.unh.edu id AA06110
  (5.65c+/IDA-1.4.4 for xerox.com!MOO-Cows.PARC); Sun, 12 Jul 1992 17:05:38 -0400
Received: by unhtel.unh.edu (smail2.5R)
	id AA24264; 12 Jul 92 17:05:29 EDT (Sun)
Received: by morwyn.UUCP id AA12450
  (5.65c/IDA-1.4.4 for MOO-Cows.PARC@xerox.com); Sun, 12 Jul 1992 17:59:25 -0400
Return-Path: <morwyn!forrie@unhtel.unh.edu>
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD001FC84C
Message-ID: <199207122159.AA12450@morwyn.UUCP>
Date:	Sun, 12 Jul 1992 14:59:08 -0700
From:	System Administrator <root@morwyn.uucp>
Sender: unhtel!morwyn!root@senex.unh.edu
To:	MOO-Cows.PARC@xerox.com
Subject: Lambda-MOO server question

| In the documentation for the MOO server, it state that it would be simple
| to write a networking module that would just 'pretend' to network. This
| would allow single-user operation on the data-base without ocupying a port
| or opening up for other people who could possible break in and interupt
| work.
| I was wondering if anyone out there had writen such a module and how I
| could get hold of it. (I'd write it myself, but i havn't gotten around to
| learing C)
[ ... ]

	Ah, this is the big esoteric question I have been asking for > 1 year,
	with no luck.  I ran into someone (aka Bloaf) on the net that claimed
	he could (and did) do this.  But alas, I haven't heard from him... nor
	have I _seen_ anything.

	Aparently, according to the author, it would be relatively easy to
	accomplish a non-networking version by hacking at the file 
	bsd_network.c, as that's where all the networking calls are performed.

	This would be really nice to see... but I'm not holding my breath.

	Most people are lucky enough to have a Unix machine that _has_
	real networking, so there isn't really a 'push' to get the SysV
	version out.  Good luck.  And if anyone out there has done it,
	or is working on it, please be kind and let us know.




From melb.bull.oz.au!lro Sun Jul 12 16:25:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "13" "July" "1992" "02:15:38" "-0700" "Liam Routt" "lro@melb.bull.oz.au " nil "20" "Re: Lambda-MOO server question" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 12 Jul 1992 16:25:10 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12018>; Sun, 12 Jul 1992 16:24:07 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12014>; Sun, 12 Jul 1992 16:22:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 12 Jul 1992 16:21:00 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12014>; Sun, 12 Jul 1992 16:20:46 PDT
Received: from sun0 ([134.211.128.101]) by alpha.xerox.com with SMTP id <12014>; Sun, 12 Jul 1992 16:20:15 PDT
Received: from terra (terra.melb.bull.oz.au) by sun0 with SMTP id AA02603
  (5.65c/IDA-1.4.4 for <MOO-Cows.PARC@xerox.com>); Mon, 13 Jul 1992 09:18:27 +1000
Received: from sx6.YP.melb.bull.oz by terra (4.1/SMI-4.0)
	id AA25260; Mon, 13 Jul 92 09:18:02 EST
X-NS-Transport-ID: 08002008D0FD001FC8D3
In-Reply-to: <9207122034.AA23141@matt.ksu.ksu.edu>
Message-ID: <QA60BD1B@sx6>
Date:	Mon, 13 Jul 1992 02:15:38 -0700
From:	lro@melb.bull.oz.au (Liam Routt)
To:	edwanji@matt.ksu.ksu.edu (Edwanji Lemorian)
cc:	MOO-Cows.PARC@xerox.com
Subject: Re: Lambda-MOO server question

    I actually did such a port about eight months ago.  It did not require
all that much work - all I did was add a startup parameter (in place of the
port the moo would use) that indicated that the system was to be "local".
    I forwarded the changed bsd_network.c file to the moo authors, but I
never heard anything back from them about it...  I guess I assumed that thye
already had such stuff and didn't need my additions...  Since then I have
moved away from creating my own moo, and I deleted the relevant
bsd_network.c file about three weeks ago...  Possibly someone over at the
Lambda moo (where I sent the code I wrote) has it somewhere?
    I could do it again, but I do not have a copy of the current server
code, nor do I have space to download the whole thing...  If you are
interested, e-mail the bsd_network.c file to me and I will have another shot
at it...  [I will be away for most of August, but I might have time before
then, and I'm sure that I could complete it after I got back...]

                                                Liam Routt
        "Murder by Pirates is Good!"            Senior Software Engineer
                    - The Princess Bride        Bull Information Systems
                                                Melbourne, AUSTRALIA


From xerox.com!parc.xerox.com.PARC Mon Jul 13 10:58:52 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "13" "July" "1992" "10:45:00" "-0700" "Winthrop D Chan" "wdc50@duts.ccc.amdahl.com " nil "8" "Lambda-MOO server questions" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 13 Jul 1992 10:58:44 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11609>; Mon, 13 Jul 1992 10:57:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11605>; Mon, 13 Jul 1992 10:53:11 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 13 Jul 1992 10:46:38 -0700
Received: from charon.amdahl.com ([129.212.11.1]) by alpha.xerox.com with SMTP id <11586>; Mon, 13 Jul 1992 10:46:12 PDT
Received: from amdahl.uts.amdahl.com (sde-hy.uts.amdahl.com) by charon.amdahl.com (4.0/SMI-4.1/DNS)
	id AA27905; Mon, 13 Jul 92 10:46:09 PDT
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.10)
	id <m0m7USh-0000pmC@amdahl.uts.amdahl.com>; Mon, 13 Jul 92 10:45 PDT
Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6)
	id <m0m7USX-0000QqC@juts.ccc.amdahl.com>; Mon, 13 Jul 92 10:45 PDT
Received: by DUTS.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.7)
	id <m0m7UT0-0000fjC@DUTS.ccc.amdahl.com>; Mon, 13 Jul 92 10:45 PDT
X-NS-Transport-ID: 08002008D0FD001FD005
Message-ID: <m0m7UT0-0000fjC@DUTS.ccc.amdahl.com>
Date:	Mon, 13 Jul 1992 10:45:00 -0700
From:	wdc50@duts.ccc.amdahl.com (Winthrop D Chan)
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: Lambda-MOO server questions

Hmmm... I thought MOO could already work on a SysV box. I guess I'll try it
out later this week. If it doesn't I'd be happy to work on porting the code,
but don't expect any results for about a few months since I'm in the middle of
another project right now. :-)

Winthrop Chan (aka Pax @ LambdaMOO)
Software Engineer
Amdahl Corp

From doc.imperial.ac.uk!mjb Mon Jul 13 13:36:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "13" "July" "1992" "13:22:37" "-0700" "mjb@doc.imperial.ac.uk" "mjb@doc.imperial.ac.uk" nil "17" "Lambda-MOO server questions" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 13 Jul 1992 13:36:45 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11689>; Mon, 13 Jul 1992 13:34:24 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11650>; Mon, 13 Jul 1992 13:31:21 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 13 Jul 1992 13:24:23 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11660>; Mon, 13 Jul 1992 13:23:59 PDT
Via: uk.ac.imperial.doc; Mon, 13 Jul 1992 21:23:34 +0100
X-NS-Transport-ID: 08002008D0FD001FD328
In-Reply-to: "Winthrop D Chan's message of Mon, 13 Jul 1992 10:45:00 PDT <m0m7UT0-0000fjC@DUTS.ccc.amdahl.com>"
Message-ID: <9207132122.aa16510@puffin.doc.ic.ac.uk>
Date:	Mon, 13 Jul 1992 13:22:37 -0700
From:	mjb@doc.imperial.ac.uk
To:	wdc50@duts.ccc.amdahl.com
cc:	moo-cows@parc.xerox.com
Subject: Lambda-MOO server questions

   Hmmm... I thought MOO could already work on a SysV box. I guess
   I'll try it out later this week. If it doesn't I'd be happy to work
   on porting the code, but don't expect any results for about a few
   months since I'm in the middle of another project right now. :-)

   Winthrop Chan (aka Pax @ LambdaMOO) Software Engineer Amdahl Corp

MOO does ... as I proved the other week by getting it to work on a
4-processor Silicon Graphics server under IRIX (SVR3).

I think what was meant was old versions of SysV without BSD sockets.

-- 
| Matthew J. Brown  | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk  | Imperial College,  | lectures He wouldn't have created |
| mjb02@cc.ic.ac.uk | 180 Queen's Gate   | double-sided photocopiers.        |
| Morven on Lambda  | LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

From senex.unh.edu!unhtel!morwyn!forrie Mon Jul 13 14:30:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "14" "July" "1992" "03:11:47" "-0700" "Forrie Aldrich" "forrie@morwyn.uucp" nil "28" "Lambda-MOO server questions" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 13 Jul 1992 14:30:05 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11684>; Mon, 13 Jul 1992 14:29:05 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11706>; Mon, 13 Jul 1992 14:25:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 13 Jul 1992 14:19:01 -0700
Received: from senex.unh.edu ([132.177.128.103]) by alpha.xerox.com with SMTP id <11699>; Mon, 13 Jul 1992 14:18:27 PDT
Received: by senex.unh.edu id AA07674
  (5.65c+/IDA-1.4.4 for parc.xerox.com!moo-cows); Mon, 13 Jul 1992 17:20:40 -0400
Received: by unhtel.unh.edu (smail2.5R)
	id AA11623; 13 Jul 92 17:20:18 EDT (Mon)
Received: by morwyn.UUCP id AA00972
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Tue, 14 Jul 1992 06:12:07 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD001FD443
Message-ID: <199207141012.AA00972@morwyn.UUCP>
Date:	Tue, 14 Jul 1992 03:11:47 -0700
From:	Forrie Aldrich <forrie@morwyn.uucp>
Sender: unhtel!morwyn!forrie@senex.unh.edu
To:	moo-cows@parc.xerox.com
Subject: Lambda-MOO server questions
Reply-to: morwyn!forrie@unhtel.unh.edu

>>>Quoting mjb@doc.imperial.ac.uk:
| 
|    Hmmm... I thought MOO could already work on a SysV box. I guess
|    I'll try it out later this week. If it doesn't I'd be happy to work
|    on porting the code, but don't expect any results for about a few
|    months since I'm in the middle of another project right now. :-)
| 
|    Winthrop Chan (aka Pax @ LambdaMOO) Software Engineer Amdahl Corp
| 
| MOO does ... as I proved the other week by getting it to work on a
| 4-processor Silicon Graphics server under IRIX (SVR3).
| 
| I think what was meant was old versions of SysV without BSD sockets.
[ ... ]

	BZZZT!  Yes, it will readily work with versions of SysV that support
	the networking code.  However, it does =not= support machines that
	are derived from SysV that do not have networking (ie SysVr2, and
	some derivatives).

	I've been looking for quite some time for someone who would be able
	to hack bsd_network.c to work with FIFOs and the such.  I do have
	some pd socket code on my system...  Pavel claims that such a port
	would not be difficult, but I have yet to see it.

	Anyone out there accomplish this?



From po.cwru.edu!yjc Sun Jul 19 19:21:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "19" "July" "1992" "20:16:49" "-0700" "yjc@po.cwru.edu" "yjc@po.cwru.edu" nil "12" "Object Representations?" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 19 Jul 1992 19:20:59 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12148>; Sun, 19 Jul 1992 19:20:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12138>; Sun, 19 Jul 1992 19:17:13 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 19 Jul 1992 19:15:29 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12133>; Sun, 19 Jul 1992 19:15:07 PDT
Received: from pop.CWRU.Edu ([129.22.4.4]) by alpha.xerox.com with SMTP id <12133>; Sun, 19 Jul 1992 19:14:28 PDT
Received: from b61539.STUDENT.CWRU.Edu by pop.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.4-ins)
	id AA29088; Sun, 19 Jul 92 22:14:00 -0400 (from yjc@po.cwru.edu for MOO-Cows@Xerox.Com)
X-NS-Transport-ID: 08002008D0FD00202367
Message-ID: <9207200214.AA29088@pop.CWRU.Edu>
Date:	Sun, 19 Jul 1992 20:16:49 -0700
From:	yjc@po.cwru.edu
To:	MOO-Cows.PARC@xerox.com
Subject: Object Representations?

  How is the universe represented in MOO? I curious as to how objects are
represented. I have this model of an object as a collection of lists. Each
list can contain lists, strings, booleans and integers. Is this how it's
done in MOO?

 

---
 Fading

"Dah Dah Dah Dah! Dum Dum DeDum!" --- Nameless Song


From netcom.com!frankc Mon Jul 27 19:13:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "27" "July" "1992" "18:59:17" "-0700" "Frank Crowell" "frankc@netcom.com " nil "40" "Re: forwarded message from Glen Daniels" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 27 Jul 1992 19:12:58 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11717>; Mon, 27 Jul 1992 19:11:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11696>; Mon, 27 Jul 1992 19:08:46 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 27 Jul 1992 19:00:04 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11670>; Mon, 27 Jul 1992 18:59:38 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA20347; Mon, 27 Jul 92 18:59:18 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002097C3
In-Reply-to: "<92Jul27.164055pdt.58372@lambda.parc.xerox.com>; from \"Pavel Curtis\" at Jul 27, 92 4:40 pm"
Message-ID: <9207280159.AA20347@netcom.netcom.com>
Date:	Mon, 27 Jul 1992 18:59:17 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	MOO-Cows@parc.xerox.com
Subject: Re: forwarded message from Glen Daniels

Most of my comments are directed towards MU* (the MUDs) in 
general, rather than MOO specifically: 

> 	Are there people in the MOO community working in any of the
> following directions?
> 
>   o  Distributed object management
>   o  Multimedia extensions + GUI clients
>   o  "real-world" MOO objects
> 	(This last would be things like being able to utilize your file
>    system, or I/O devices, or the network, from within a MOO (sit down at
>    a virtual VT100 in a MOO terminal room, for instance, and be able to
>    telnet))

These topics (except multimedia and gui) were briefly discussed in
this newsgroup. But no one indicated that they actually were working
on any of these implementations.  In the MU* world in general,
Unter offers portable objects and distributed rooms. In the LPmud
(combat) there are a couple graphical clients (kinda crude yet).
Simple bitmap display should not be too hard with a decent GUI client.
Full real-time, asynch, multimedia is fairly hard to do right now;
this may change in a couple of years, though.


> 	I'm unbelievably psyched about this direction in computer
> technology.  My new company, ELF Communications, has been discussing
> making a MOO-accessible office area in which users can look through
> catalogs, try out software, ask tech-support questions, attend
> seminars given by guests every once in a while, and purchase
> software....
> 
I would think there should be a great deal of interest
in this area. the 'online' business now caters to some of
these activities with a collection of different software.  
I think that a MU* environment would be ideal. 


-- 
Frank Crowell frankc@netcom.COM
Netcom - Online Communication Services San Jose, CA

From pavel Tue Jul 28 11:16:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil]
	[nil "Tue" "28" "July" "1992" "11:16:00" "-0700" "Pavel Curtis" "Pavel" nil "43" "forwarded message from Glen Daniels" "^Date:" nil nil "7"])
Received: from lambda.parc.xerox.com ([13.2.116.36]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 28 Jul 1992 11:16:15 -0700
Received: by lambda.parc.xerox.com id <58372>; Tue, 28 Jul 1992 11:16:00 -0700
Fake-Sender: pavel@parc.xerox.com
Message-Id: <92Jul28.111600pdt.58372@lambda.parc.xerox.com>
Date:	Tue, 28 Jul 1992 11:16:00 -0700
From:	Pavel Curtis <Pavel>
Sender: Pavel Curtis <pavel>
To:	MOO-Cows@Xerox.Com
Subject: forwarded message from Glen Daniels

Glen Daniels just joined the MOO-Cows mailing list and sent me the following
note, which I thought might best get answered in this wider forum.

	Pavel/Haakon

------- Start of forwarded message -------
Date:	Mon, 27 Jul 1992 12:07:14 -0700
From:	gub@asylum.sf.ca.us (Glen Daniels)

I have a couple of questions:

	Are there people in the MOO community working in any of the
following directions?

  o  Distributed object management
  o  Multimedia extensions + GUI clients
  o  "real-world" MOO objects
	(This last would be things like being able to utilize your file
   system, or I/O devices, or the network, from within a MOO (sit down at
   a virtual VT100 in a MOO terminal room, for instance, and be able to
   telnet))

	These are all topics which interest me very much.

	Also, I'm just getting started with MOO development.  Is it
possible for a user who is not the owner of a given room to see what
exits it has, aside from relying on the description?  In other words,
is there a notion of "obvious exits" similar to the "obvious verbs" on
normal objects?

	I'm unbelievably psyched about this direction in computer
technology.  My new company, ELF Communications, has been discussing
making a MOO-accessible office area in which users can look through
catalogs, try out software, ask tech-support questions, attend
seminars given by guests every once in a while, and purchase
software....

	The adventure is just beginning,

		--Gub (Glen Daniels, gub@elf.com)


------- End of forwarded message -------

From casbah.acns.nwu.edu!hpa Wed Jul 29 23:27:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "29" "July" "1992" "23:19:32" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " "<9207300619.AA01333@casbah.acns.nwu.edu>" "20" "x.wizard = 1" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Wed, 29 Jul 1992 23:27:08 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11990>; Wed, 29 Jul 1992 23:26:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11980>; Wed, 29 Jul 1992 23:22:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 29 Jul 1992 23:20:02 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11977>; Wed, 29 Jul 1992 23:19:35 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA01333; Thu, 30 Jul 92 01:19:33 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0020C081
Message-ID: <9207300619.AA01333@casbah.acns.nwu.edu>
Date:	Wed, 29 Jul 1992 23:19:32 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: x.wizard = 1
Reply-to: hpa@nwu.edu

Hello, Haakon & other wizzes:

version 1.5.20 of the LambdaMOO server supposedly implements some form of
security control against players hacking wizbits for themselves.  Since I
am rather concerned about that, I just upgraded the server on my system,
DalMOO (currently under development).

If anyone could please inform me about the proper operation of this
security device (including how to actually make a wizard if 
"; #123.wizard = 1" is no longer permitted.

Thanks,

	/hpa - Zytor - Xorbon

-- 
INTERNET: hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:   HPA@NUACC     HAM RADIO: N9ITP, SM4TKN
IRC:      Scalar        NeXTMAIL:  hpa@lenny.acns.nwu.edu
Have you kissed your Swede today?

From parc.xerox.com!pavel Thu Jul 30 15:13:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "30" "July" "1992" "15:04:02" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "23" "Re: x.wizard = 1" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 30 Jul 1992 15:13:32 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11673>; Thu, 30 Jul 1992 15:11:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11661>; Thu, 30 Jul 1992 15:08:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 30 Jul 1992 15:04:47 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11638>; Thu, 30 Jul 1992 15:04:22 PDT
Received: by lambda.parc.xerox.com id <58372>; Thu, 30 Jul 1992 15:04:16 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0020CEE3
In-Reply-to: <9207300619.AA01333@casbah.acns.nwu.edu>
Message-ID: <92Jul30.150416pdt.58372@lambda.parc.xerox.com>
References: <9207300619.AA01333@casbah.acns.nwu.edu>
Date:	Thu, 30 Jul 1992 15:04:02 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	hpa@nwu.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: x.wizard = 1

> Date:	Wed, 29 Jul 1992 23:19:32 -0700
> From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
> 
> version 1.5.20 of the LambdaMOO server supposedly implements some form of
> security control against players hacking wizbits for themselves.  Since I
> am rather concerned about that, I just upgraded the server on my system,
> DalMOO (currently under development).
> 
> If anyone could please inform me about the proper operation of this
> security device (including how to actually make a wizard if 
> "; #123.wizard = 1" is no longer permitted.

You are, I'm afraid, laboring under a misapprehension concerning the change in
Version 1.5.20.  Quoting from the file ChangeLog.txt:

	-- Added logging of all instances of x.wizard = 1.

The server does not in any new way *prevent* wizard bits from being set.
Rather, it simply writes an entry to the server log each time it happens.
Quite possibly, in the next release, the entry in the log will include a full
backtrace of the running task.

	Pavel/Haakon

From computing-maths.cardiff.ac.uk!Andrew.Wilson Fri Jul 31 11:42:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "31" "July" "1992" "10:49:24" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "188" "Inter-MOO communication..." "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 31 Jul 1992 11:40:54 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11853>; Fri, 31 Jul 1992 11:29:34 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11757>; Fri, 31 Jul 1992 11:01:51 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 31 Jul 1992 10:50:50 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11760>; Fri, 31 Jul 1992 10:49:51 PDT
Via: uk.ac.cardiff.computing-maths; Fri, 31 Jul 1992 18:49:43 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <18097-0@sentinel.cm.cf.ac.uk>; Fri, 31 Jul 1992 18:49:28 +0100
X-NS-Transport-ID: 08002008D0FD0020DB37
Message-ID: <9207311749.AA23313@amethyst.cm.cf.ac.uk>
Date:	Fri, 31 Jul 1992 10:49:24 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com, Andrew.Wilson@computing-maths.cardiff.ac.uk
Subject: Inter-MOO communication...



Hi,
	has anyone had a serious look at allowing MOOs to communicate?

I'm experimenting with the idea of a 'virtual' room, sort of VR in VR
if you like.  To the player, a virtual room (a VROOM) looks like any other
and has a single exit 'out'.  When a player enters a VROOM she/he/it can
interact with other players that appear in the room by use of the commands
'say' and 'emote'.  Typing 'look' works the same way too.
	So far, so what!  Well, it works out that not ALL the players
you see when you enter a VROOM are PHYSICALLY located on the same MOO as
you!

To allow two different MOOs to communicate, each will need to know:

  1.	The site name and port number of the other's MOO server.
  2.	The name and password of a 'special' player on the other MOO.

Let's say that there are two sites, LambdaMOO and GodNet that want to
set up a connection to allow their players to talk to one another.

At LambdaMOO, a special player is created for the GodNet MOO to use:

	create JeanMichel heretic

and JeanMichel's home is set to be a VROOM in LambdaMOO.

At GodNet, a special player is created for the LambdaMOO MOO to use:

	create SurfMonster wipeout

and SurfMonster's home is set to be a VROOM in GodNet.

The players JeanMichel and SurfMonster are both VPLAYERs, a class which inherits
from the player class and has a few extra verbs defined on it.

Now we need to join the MOOs together.  This could be done
automatically, but let's assume a wizard at each site makes the connection.
A wiz at LambdaMOO would execute code defined for the VROOM that looked
something like:

	"$vroom:listen
	$vroom.vplayer = open_network_connection("godnet.somewhere.edu", 7777);
	notify($vroom.vplayer, "connect SurfMonster wipeout");
	while (1) 
		line = read($vroom.vplayer);
		fork (0)
			$vroom:broadcast(line)
		endfork
	endwhile

Where $vroom:broadcast(line) is a verb which displays 'line' to
every player in the VROOM.  It does NOT send 'line' to any VPLAYERs in the room.
	
Thereafter, read(vplayer) would read from the connection set up between
LambdaMOO and SurfMonster on GodNet.

Now suppose that people in SurfMonster's VROOM on GodNet start talking:

Frederique is standing next to SurfMonster and says:

	"Hello everyone!

SurfMonster sees this and GodNet's server sends all the things that SurfMonster
sees back down the connection to LambdaMoo.  At LambdaMoo, the code
defined in $vroom:listen which is listening to the connection to GodNet
picks up the string 'Hello everyone!' and broadcasts it to every non VPLAYER
in the VROOM.

BigMac is standing in LamdaMOO's VROOM and hears (sees):

	Frederique says, Hello everyone!

(This WORKS!!  It DEFINETELY works.)

So far we have it that players in the LambdaMOO VROOM can 'hear'
and 'see' everything that happens in the VROOM at GodNet.  But when BigMac
types 'look' all he/she/it gets is a description of the VROOM in LambdaMOO.

To take this description further lets assume that a wizard at GodNet has
connected to LambdaMOO using the VPLAYER JeanMichel.  So things look
like this:

LambdaMOO
+-----------------------+
|			|
|	BigMac		|
|			|
|	JeanMichel<-----+---+
|			|   |
+-----------------------+   |
		   ^        |
		   |        |	GodNet
		   |        |	+-----------------------+
		   |        |	|			|
		   |        +-->|	Frederique	|
		   |    	|			|
		   +------------+------>SurfMonster	|
				|			|
				+-----------------------+


Ok, so redefine $vroom:look so that it:
	1. Prints a description of the GodNet VROOM and its contents and then;
	2. Prints a description of the LambdaMOO room and its contents.
The nasty way to do this is for the code for 'look' to ask SurfMonster what
he can see in GodNet's VROOM.  You could code this as:

	"$vroom:look
	notify($vroom.vplayer, "look");
	pass(args)

And when SurfMonster 'looks' in GodNet's VROOM all the text that he sees
will be delivered back down the connection to LambdaMOO and will be broadcast
to BigMac.  The code will then call the ordinary 'look' verb for $room.

So then, BigMac typed 'look' and the reply was:

	This is GodNet's VROOM, a connection to the MOOniverse.
	Beware, not everyone you see is really here!
	Frederique and SurfMonster are here.
	This is LambdaMOOs VROOM, a link to all known MOOs.
	People and things are NOT as they seem.
	JeanMichel is here.

Not perfect, but details are usually someone else's problem I find!
A better response would be (perhaps) for both VROOMS to have the same
descriptions and to have some way of getting a list of player names from
the GodNet room.  Basically I'm thinking along the lines of:

	$vplayer:who_else
		"print out the names of players in my vroom
		<Some code>

So then $vroom:look would look like:

	"$vroom:look a better version:
	pass(args);
	notify($vroom.vplayer, "who_else");

So now when BigMac types 'look' he gets:

	This is a VROOM.
	People and things are not as they seem.
	JeanMichel is here.
	Frederique and SurfMonster are here.

Like I said, details.

RECAP:

	We can connect two MOOs together and set up two-way communications
using VPLAYERs to transmit and recieve information.  To do this we
need to know the name and password of a VPLAYER on another site and that
VPLAYER needs to be in a VROOM.  Players can then interact with 'say',
'emote' and 'look' and can be understood by players on other MOOs.
This does NOT mean that you can 'take' anything that appears in the description
from the 'other' MOO's VROOM.

FUTURE DEVELOPEMENTS:

	Why limit it to two-way communications?  Become an ambassador
for your MOO!  Get a VPLAYER set up on another site, make a VPLAYER for
that site to use as well and hack your 'listen' verb so that it connects
you to that site too!  Just imagine!  A VROOM linking 3 or 4 or 5 MOOs
all at the same time.  Millions of people to talk to and none of them
really in the same room as you!  (Sounds familiar).

	You COULD make it even more simple to implement by placing
all the VROOM-specific code in VPLAYER.  So VPLAYER will execute the 'look'
code.  Details, details!  Let someone else do the thinking for a while!

DEEP BREATH:

Please note:  I'm not suggesting a mechanism for physically transferring
objects between MOOs.  I'm just trying to set up a way for players
on different MOOs to communicate.

Has anyone done this already and if not WHY NOT!  Post replies to
moo-cows@parc.xerox.com so we can all join in.

Luv,
	Andrew Wilson - Wizard @ Various MOOs Nobody's Ever Heard Of!
		      - A PhD by October, hopefully.

ps.  My understanding of 'processes' in MOO is a little flakey.  So the code
might not be 100% correct.  It works for me though, as far as I know.

From andrew.cmu.edu!jt1o+ Fri Jul 31 12:02:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "31" "July" "1992" "11:48:09" "-0700" "Moonchilde" "jtraub+@cmu.edu" nil "25" "Just some general questions and a request." "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 31 Jul 1992 12:02:17 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11790>; Fri, 31 Jul 1992 12:01:16 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11652>; Fri, 31 Jul 1992 11:58:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Fri, 31 Jul 1992 11:49:44 -0700
Received: from po2.andrew.cmu.edu ([128.2.249.105]) by alpha.xerox.com with SMTP id <11630>; Fri, 31 Jul 1992 11:49:23 PDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA02914> for moo-cows@parc.xerox.com; Fri, 31 Jul 92 14:49:15 EDT
Received: via switchmail; Fri, 31 Jul 1992 14:49:14 -0400 (EDT)
Received: from freehold.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.4eSMfw600WD5IyIk4U>;
          Fri, 31 Jul 1992 14:48:29 -0400 (EDT)
Received: via niftymail; Fri, 31 Jul 1992 14:48:10 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD0020DC33
Message-ID: <712608489.15850.0@freehold.andrew.cmu.edu>
Date:	Fri, 31 Jul 1992 11:48:09 -0700
From:	Moonchilde <jtraub+@cmu.edu>
Sender: jt1o+@andrew.cmu.edu
To:	moo-cows@parc.xerox.com
Subject: Just some general questions and a request.

Okay, questions first.
Haakon: do you have any plans to add the GodNET regexp and listassoc
code to the standard MOO release? it's really a pain to keep patching them
in. :)

Also, compiling MOO under a MACH 3.0 system led to some interesting
difficulties which I will summarize along with how I needed to fix them.
I was using the ultrix cc compiler since it produces faster and tighter code
on pmaxen.

First:  in my-time.h, MACH systems need the sys/types include.
Second: in server.c.  remove() wasn't found as a function. Unlink() seems to
        be more standard.
Third:  in add_property(): ultrix cc doesn't like the automatic initialization
        of value.  Just decalre value and initialize it seperately.

Lastly, a request
  I would like a function similar to notify() that does not append the output
text with a newline/line feed.  This would make interactive prompting look
a little cleaner, and shouldn't be all that hard to do.  However, it would
be rather extensive to do, and I haven't had the time to take the time to 
actually go and do what needs to be done to make it work.  So this is a 
request if anyone else has the time and energy and is willing to do it.

--Moonchilde

From andrew.cmu.edu!jt1o+ Fri Jul 31 12:11:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "31" "July" "1992" "11:55:57" "-0700" "Moonchilde" "jtraub+@cmu.edu" nil "8" "One other problem with MOO under Mach." "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 31 Jul 1992 12:11:03 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11795>; Fri, 31 Jul 1992 12:09:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11778>; Fri, 31 Jul 1992 12:06:50 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Fri, 31 Jul 1992 11:58:34 -0700
Received: from po5.andrew.cmu.edu ([128.2.10.105]) by alpha.xerox.com with SMTP id <11755>; Fri, 31 Jul 1992 11:57:35 PDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA19245> for moo-cows@parc.xerox.com; Fri, 31 Jul 92 14:57:24 EDT
Received: via switchmail; Fri, 31 Jul 1992 14:57:22 -0400 (EDT)
Received: from freehold.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.YeSMn2y00WD58yRk5h>;
          Fri, 31 Jul 1992 14:56:03 -0400 (EDT)
Received: via niftymail; Fri, 31 Jul 1992 14:55:58 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD0020DC62
Message-ID: <712608957.15850.0@freehold.andrew.cmu.edu>
Date:	Fri, 31 Jul 1992 11:55:57 -0700
From:	Moonchilde <jtraub+@cmu.edu>
Sender: jt1o+@andrew.cmu.edu
To:	moo-cows@parc.xerox.com
Subject: One other problem with MOO under Mach.

There is one other function that standard mach 3.0 does not define.
strftime.  I got strftime.c from the uunet sources, and with one
small modification, was able to compile it and link it into the MOO code.
Just for information purposes.  However Haakon: it might be better to use
either asctime() or write your own version of strftime() to distribute with
the MOO code from hereon out.

--JT

From ais.org!jgm Fri Jul 31 12:19:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "31" "July" "1992" "12:00:34" "-0700" "Jim Miller" "jgm@ais.org " nil "17" "Re: Inter-MOO Communication" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 31 Jul 1992 12:19:04 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11773>; Fri, 31 Jul 1992 12:16:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11779>; Fri, 31 Jul 1992 12:13:30 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Fri, 31 Jul 1992 12:07:02 -0700
Received: from ais.org ([141.211.206.16]) by alpha.xerox.com with SMTP id <11796>; Fri, 31 Jul 1992 12:00:42 PDT
Received: by ais.org (/\==/\ Smail3.1.25.1 #25.14)
	id <m0mE2DL-0002bQC@ais.org>; Fri, 31 Jul 92 15:00 EDT
X-NS-Transport-ID: 08002008D0FD0020DC7D
Message-ID: <m0mE2DL-0002bQC@ais.org>
Date:	Fri, 31 Jul 1992 12:00:34 -0700
From:	jgm@ais.org (Jim Miller)
To:	moo-cows@parc.xerox.com
Subject: Re: Inter-MOO Communication

I have done exactly what you are describing between 2 tinymucks --
no object transference, just communication.  Players in a certain
room on one muck can execute commands on the other muck, including
page, look, WHO (@who), kill, and any others that I choose to include.
I'm using a set of macros for the latest version of tinyfugue (2.0)
to accomplish this, and a short program in the muck server language
on both ends.  I could probably do it without using a program, and
the principle of using mud client macros to accomplish the communication
can apply to any type of mud.



-- 
'Subverting melodic authority by challenging oppressive tonal hierarchies,
Madonna decimates "patriarchal, racist, and capitalist constructions" simply
in the way she bellows out "self" in the line "Express your_self_"'
     -- Daniel Harris on Melanie Morton

From casbah.acns.nwu.edu!hpa Fri Jul 31 13:28:17 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "31" "July" "1992" "13:16:30" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "43" "Re: Inter-MOO communication..." "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 31 Jul 1992 13:28:12 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11770>; Fri, 31 Jul 1992 13:26:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11787>; Fri, 31 Jul 1992 13:25:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 31 Jul 1992 13:17:06 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11748>; Fri, 31 Jul 1992 13:16:34 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA23341; Fri, 31 Jul 92 15:16:30 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0020DDAD
Message-ID: <9207312016.AA23341@casbah.acns.nwu.edu>
Date:	Fri, 31 Jul 1992 13:16:30 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: Re: Inter-MOO communication...
Reply-to: hpa@nwu.edu

You write:
> 
> Hi,
> 	has anyone had a serious look at allowing MOOs to communicate?
> 
> I'm experimenting with the idea of a 'virtual' room, sort of VR in VR
> if you like.  To the player, a virtual room (a VROOM) looks like any other
> and has a single exit 'out'.  When a player enters a VROOM she/he/it can
> interact with other players that appear in the room by use of the commands
> 'say' and 'emote'.  Typing 'look' works the same way too.
> 	So far, so what!  Well, it works out that not ALL the players
> you see when you enter a VROOM are PHYSICALLY located on the same MOO as
> you!
> 

Hi there.
I have played with exactly the same idea; combined with ideas of MOO ports
and similar devices.

One of the snags is that most (?) MOOs have OUTBOUND_NETWORK disabled,
although that could be taken care of in its own way; in peculiar someone at
one end could make a small transfer client.

It should not be that difficult to create such transfer devices, in fact
the only limitation is your imagination.  It is possible that it could be
extended to "virtual exits"; which would connect a player to a different
MOO while keeping compatible characteristics, such as name, gender, aliases
and description.  Beyond a certain point, however, it is almost certain
that a dedicated client is needed.

I noted you are "a wizard of several MOOs noone has ever heard of".  If you
want to experiment with the idea, we could make an attempt to connect one
of those with my sytem, DalMOO, although it is not yet open to the public
(it will sometime this fall).

	/hpa


-- 
INTERNET: hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:   HPA@NUACC     HAM RADIO: N9ITP, SM4TKN
IRC:      Scalar        NeXTMAIL:  hpa@lenny.acns.nwu.edu
"Kissing a smoker is like licking an ashtray."  -- R. Heinlein

From netcom.com!frankc Fri Jul 31 14:53:23 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "31" "July" "1992" "14:49:20" "-0700" "Frank Crowell" "frankc@netcom.com " nil "17" "Re: Inter-MOO communication..." "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Fri, 31 Jul 1992 14:53:21 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11794>; Fri, 31 Jul 1992 14:52:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11776>; Fri, 31 Jul 1992 14:51:30 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 31 Jul 1992 14:50:09 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11771>; Fri, 31 Jul 1992 14:49:42 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA12751; Fri, 31 Jul 92 14:49:21 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0020DF46
In-Reply-to: "<9207311749.AA23313@amethyst.cm.cf.ac.uk>; from \"Andrew Wilson\" at Jul 31, 92 10:49 ame other "
Message-ID: <9207312149.AA12751@netcom.netcom.com>
Date:	Fri, 31 Jul 1992 14:49:20 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Re: Inter-MOO communication...


First of all, i like the idea of VROOM; it allows for a lot
of multi-MOO interactions without having to deal with nasty
details such as characters and objects moving all around the  
different servers.

So my question is how are whispers handled?
	-everone hears				say <msg>
	-only those on serverA hear		w serverA <msg>
	-only Cybercrud hears			w Cybercrud <msg>

Finally, do you think its strange that we handle all those MOO
issues through email?  After, many of us claim that MU* can be
used for things other than games and role-playing.  Its seems
that the best way to learn and advance MU* ideas is through a MU*
Laboratory. I find it strange that the Mud Institute is the only
site that offers such an environment for LPmud and MUDOS.

From theory.cs.mankato.msus.edu!nop Sat Aug  1 02:04:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "01:52:58" "-0700" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "18" "Inter-MOO communication..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 1 Aug 1992 02:04:17 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11716>; Sat, 1 Aug 1992 02:03:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11768>; Sat, 1 Aug 1992 02:00:36 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 1 Aug 1992 01:53:53 -0700
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11716>; Sat, 1 Aug 1992 01:53:21 PDT
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA18858; Sat, 1 Aug 92 03:52:58 -0500
X-NS-Transport-ID: 08002008D0FD0020E4DD
In-Reply-to: "Frank Crowell's message of Fri, 31 Jul 1992 14:49:20 PDT <9207312149.AA12751@netcom.netcom.com>"
Message-ID: <9208010852.AA18858@theory.cs.mankato.msus.edu>
Date:	Sat, 1 Aug 1992 01:52:58 -0700
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	frankc@netcom.com
cc:	moo-cows@parc.xerox.com
Subject: Inter-MOO communication...

> Its seems that the best way to learn and advance MU* ideas is
> through a MU* Laboratory. I find it strange that the Mud Institute
> is the only site that offers such an environment for LPmud and
> MUDOS.

The original intention of DistortionMOO was to give people a place to
fool around with ideas like this without having to worry about
breaking stuff for a huge (non-programmer) populace.  We seem to have
stagnated worrying about correctness issues, though.  Perhaps it's
time to revive the original concept.  I'd offer Distortion, but I'm
not sure I want to break its theoretical correctness (and believe me,
any correctness it has is in theory, both literally and figuratively.)

:ducks vegetables from Distortion pun-haters.

Anybody have a site for an all-programmer chaos MOO?

--Jonny, archwizard of Distortion Midwest

From ee.ualberta.ca!daum Sat Aug  1 16:13:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "10:42:10" "-0700" "Ryan Daum" "daum@ee.ualberta.ca" nil "17" "Re: the \"MOO Institute\"" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sat, 1 Aug 1992 16:13:15 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11890>; Sat, 1 Aug 1992 16:05:25 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11885>; Sat, 1 Aug 1992 16:04:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Sat, 1 Aug 1992 16:00:37 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11874>; Sat, 1 Aug 1992 15:24:19 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11971>; Sat, 1 Aug 1992 10:42:23 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA04577; Sat, 1 Aug 92 11:42:11 -0600
Full-Name: Ryan Daum
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD0020F22C
In-Reply-to: "<9208010852.AA18858@theory.cs.mankato.msus.edu>; from \"Jay A. Carlson\" at Aug 1, 92 1:52 am"
Message-ID: <92Aug1.104223pdt.11971@alpha.xerox.com>
Date:	Sat, 1 Aug 1992 10:42:10 -0700
From:	Ryan Daum <daum@ee.ualberta.ca>
To:	moo-cows.PARC@xerox.com
Subject: Re: the "MOO Institute"

> 
> Anybody have a site for an all-programmer chaos MOO?
> 
> --Jonny, archwizard of Distortion Midwest
> 

Hi, it's Comrade.

I have a site available for a all programmer chaos MUD, but I'm not sure MOO is the best system to run for such a system.

It seems to me that the problems of MOO (speed, database size, lack of multinheritance, hardwired parser, fixed permissions, etc.) outweigh it's value in a new MUD.

I'm looking at CoolMUD with more and more seriousness everyday now.  All it will take is someone with "C" programing ability to add an `eval' builtin to it (which is a necessity.)

I *can* put up a all-programmer "chaos" MOO -- in fact I basically did that with Floodplain.  The thing is, I think MOO is on it's way down in comparison to the power of both FMPL and CoolMUD.

	-- Comrade Sandino

From cheshire.oxy.edu!t_pascal Sat Aug  1 16:13:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "14:52:11" "-0700" "C. Regis Wilson" "t_pascal@cheshire.oxy.edu " nil "14" "Re: ChaosMOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 16:13:14 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11888>; Sat, 1 Aug 1992 16:02:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11883>; Sat, 1 Aug 1992 16:00:44 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Sat, 1 Aug 1992 15:56:57 -0700
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <11888>; Sat, 1 Aug 1992 14:52:14 PDT
Received: from cheshire.oxy.edu by gate.oxy.edu (4.0/SMI-4.0)
	id AA06924; Sat, 1 Aug 92 14:52:42 PDT
Received: by cheshire.oxy.edu (4.1/SMI-4.1)
	id AA19277; Sat, 1 Aug 92 14:52:11 PDT
X-NS-Transport-ID: 08002008D0FD0020F278
Message-ID: <9208012152.AA19277@cheshire.oxy.edu>
Date:	Sat, 1 Aug 1992 14:52:11 -0700
From:	t_pascal@cheshire.oxy.edu (C. Regis Wilson)
To:	moo-cows@parc.xerox.com
Subject: Re: ChaosMOO


One small change in the address...

jaguar.math.oxy.edu 8888
       ^^^^

Enjoy.

---------
T. Pascal, King of Pascal    |  "The man on the moon told us he subsisted by
1600 Campus Road, Box 829    |   digging up cheese from his back yard.
Los Angeles, CA 90041        |   Unfortunately, he never told us what kind
                             |   it was."  -Word Perfect to PCWrite manual
   t_pascal@{{{cub,jaguar,cheetah}.math},bobcat,cheshire,tiger}.oxy.edu 

From computing-maths.cardiff.ac.uk!Andrew.Wilson Sat Aug  1 16:14:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "13:26:44" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "25" "" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 16:14:00 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11884>; Sat, 1 Aug 1992 15:54:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11882>; Sat, 1 Aug 1992 15:53:08 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Sat, 1 Aug 1992 15:47:36 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <12536>; Sat, 1 Aug 1992 13:35:53 PDT
Via: uk.ac.cardiff.computing-maths; Sat, 1 Aug 1992 21:27:10 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <09765-0@sentinel.cm.cf.ac.uk>; Sat, 1 Aug 1992 21:26:51 +0100
X-NS-Transport-ID: 08002008D0FD0020F271
Message-ID: <9208012026.AA29853@sapphire.cm.cf.ac.uk>
Date:	Sat, 1 Aug 1992 13:26:44 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com

Sorry,
	in my last epic:

>...
>At the MOO site which created the VPLAYER, the verb VPLAYER:ask_whisper()
>is then called called:
>...

should have read:

>...
>At each of the other MOO sites the verb VPLAYER:ask_whisper() will be
>called in the VPLAYER created for THIS site:
>...

Logic eh?  Who needs it!

You're almost there though, keep going.

Andrew.






From computing-maths.cardiff.ac.uk!Andrew.Wilson Sat Aug  1 16:16:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "09:13:31" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "171" "Inter-MOO communication II" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 16:16:01 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11877>; Sat, 1 Aug 1992 15:46:03 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11874>; Sat, 1 Aug 1992 15:43:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 1 Aug 1992 09:14:28 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11907>; Sat, 1 Aug 1992 09:14:02 PDT
Via: uk.ac.cardiff.computing-maths; Sat, 1 Aug 1992 17:13:56 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <06720-0@sentinel.cm.cf.ac.uk>; Sat, 1 Aug 1992 17:13:39 +0100
X-NS-Transport-ID: 08002008D0FD0020F26B
Message-ID: <9208011613.AA29726@sapphire.cm.cf.ac.uk>
Date:	Sat, 1 Aug 1992 09:13:31 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com, Andrew.Wilson@computing-maths.cardiff.ac.uk
Subject: Inter-MOO communication II


Hi,
	this is me thinking out loud:

Some definitions:

	A VROOM is a notional room made of other rooms which may be
	physically located on other MOOs.  The room components of
	a VROOM are linked by using VPLAYERS to 'listen to' other
	occupants in the VROOM and by special 'listening' verbs
	which broadcast what a VPLAYER hears to occupants of the
	room which connected the VPLAYER to the VROOM.

	A VPLAYER is a special type of player.  MOOs which wish
	to connect to a VROOM cause a VPLAYER to be created in the VROOM.
	The action of the MOO server causes everything that the VPLAYER
	'hears' or 'sees' to be transmitted back to the MOO site that
	created the VPLAYER.

	For example: In a typical arrangement the MOOs LambdaMOO,
	GodNet, DistortionMOO and DalMOO agree that a VROOM connecting
	all the MOOs together will be set up on LambdaMOO.
	LambdaMOO creates a VPLAYER for each of the other MOOs and sets
	the VPLAYER's 'home' to be a special room on LambdaMOO.
		Then, each MOO site in turn creates a different VPLAYER for
	LambdaMOO to use and 'home's their VPLAYER to a special room
	on their MOO.
		Connection is establised in the following way:
	At LambdaMOO a special verb is invoked which connects to LambdaMOO's
	designated VPLAYER at each of the MOO sites.  A special verb
	is made to 'listen' to what each VPLAYER hears and to broadcast it
	to other players and VPLAYERs in the special room at LambdaMOO.
	At the same time, and at each of the other MOO sites, a connection
	is made to that site's designated VPLAYER on LambdaMOO and information
	that the VPLAYER hears is broadcast to the other occupants of
	that site's special room.
	

frankc@netcom.com (Frank Crowell) says:
>So my question is how are whispers handled?
>	-everone hears				say <msg>
>	-only those on serverA hear		w serverA <msg>
>	-only Cybercrud hears			w Cybercrud <msg>

Well, VROOMs should act the same way as $rooms do.  A 'say':

	say Hello everyone!

should be heard by all occupants of a VROOM.  A 'whisper' from Philippe:

	whisper Are you doing anything tonight? to Frederique

SHOULD only be heard by Frederique.  And if Frederique is in the same room
as Philippe then there are no problems because a conventional (LambdaCore)
verb will be able to find Frederique in the same room as Philippe.  So
Frederique would see:

	Philippe whispers, 'Are you doing anything tonight?'.

and other occupants of the VROOM might see:

	Philippe whispers something to Frederique.

But things are more difficult if Frederique and Philippe are on different
MOOs.  The conventional whisper verb will fail to find Frederique because
she isn't in the same physical room as Philippe.  What should happen
is that the command from Phillipe:

	whisper <whatever> to Frederique

would be routed out to whichever MOO Frederique is on.

Because the parser failed to find a Frederique to call a whisper
verb for in Philippe's room it will instead call the verb $room:huh
[page 13 of LambdaMOO Programmer's Manual] to effect some error recovery.

A redefined VROOM:huh would 'ask' each of the VPLAYERs that it has defined
in the other MOO sites to handle the whisper. So we'd have a verb which looked
SOMETHING like:

	"VROOM:huh

	if (is_a_whisper(args)) 
		for vp in (this.vplayers)
			vp:notify("ask_whisper", player.name, args);
		endfor;
	endif;
	.

Note that the calling player's name is also passed to the VPLAYER along with
the whispered arguments.

At the MOO site which created the VPLAYER, the verb VPLAYER:ask_whisper()
is then called called:

	"VPLAYER:ask_whisper
	whisper_for = arg[1];
	whisper_to = arg[2];
	whisper_what = arg[3..length(args)];
	for p in (players_in_This_room())
		if (p.name == whisper_to)
			p:tell(whisper_for, " whispers, \"", whisper_what, "\"");
		endif;
	endfor;

Phew!

hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP) says:
>One of the snags is that most (?) MOOs have OUTBOUND_NETWORK disabled,
>although that could be taken care of in its own way; in peculiar someone at
>one end could make a small transfer client.

Why not take a leaf out of LPmud's book and 'protect' open_network_connection()
to prevent its misuse.  Make it so that the server checks to see if
the object that invoked the connection is owned by a wizard or some similar
high level person.  If the object doesn't have the right permissions then
simply return E_PERM or something meaningful to the caller.  I don't
agree that this is seriously changing the semantics of MOO in a way
that would invalidate existing code on many sites.  If the function is
so dangerous that it needs a -DCOMPILERDIRECTIVE to prevent its misuse then
why bother having it at all.  EVERY MOO should have o_n_c() capability,
it's up to the admins to see that it's not misused and 'hard coding'
permissions is one helpful way of doing this.

Ryan Daum <daum@ee.ualberta.ca> says:
>Lag presents another problem.  If I send ;4+4 to the other MOO, I have no way of
>telling if the value returned belogns to ;4+4 or the previous eval ;4+3.  I am 
>thinking of hacking a special verb that assigns a unique number to each eval
>statement, but even this has it's problems.

I can imagine!  Things are already beginning to get seriously complex, before
you know it we'll all be reading up on distributed database theory and messing
about with parallelised query processing to get the job done.  For now
I think it's best if things are kept as simple as possible.  State of the art?:
How about a VBULLETINBOARD!  Each room in the VROOM has a bulletin board
which forms part of the VROOM's VBULLETINBOARD.  Players in the VROOM
can access the VBULLETINBOARD like they would any other bulletin board.
But requests like:

	read 22 on board

Would make the VBULLETINBOARD search each of the boards on the other MOO sites
for whatever message the player requested.  So as far as the VBULLETINBOARD
(let's call it a VBOARD from now on, less typing!) is concerned:

	Messages 1 to 5 are on LambdaMOO's board,
	Messages 6 to 12 are on GodNet's board,
	Messages 13 to 15 are on DistortionMOO's board and
	Messages 15 to 24 are on DalMOO's board.

So message 8 on DalMOO's board is the one that the player sees.

Now THAT should be REALLY easy to implement!  But I'll leave the details
for someone else for now.

Andrew Wilson	-	Someone HAS to do it, but why does it always
			have to be me?











	
	


From cheetah.math.oxy.edu!t_pascal Sat Aug  1 16:17:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "14:14:38" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "18" "ChaosMOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 16:17:01 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11878>; Sat, 1 Aug 1992 15:58:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11881>; Sat, 1 Aug 1992 15:57:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Sat, 1 Aug 1992 15:52:59 -0700
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <12583>; Sat, 1 Aug 1992 14:23:19 PDT
Received: from jaguar.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA09071; Sat, 1 Aug 92 14:14:39 PDT
Received: by jaguar.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05545; Sat, 1 Aug 92 14:14:38 PDT
X-NS-Transport-ID: 08002008D0FD0020F275
Message-ID: <9208012114.AA09071@cheetah.math.oxy.edu>
Date:	Sat, 1 Aug 1992 14:14:38 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	moo-cows@parc.xerox.com
Subject: ChaosMOO


>Anybody have a site for an all-programmer chaos MOO?

jaguar.oxy.edu 8888

All players will be created as wizards.  Enjoy.  Remember, though, if
things go awry, the db will be destroyed and restarted.  Please use the
maturity I know you all have.

cheerfully,


---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
...!gate.oxy.edu!t_pascal t_pascal@{cub.math,jaguar.math,bobcat,tiger}.oxy.edu

From nova.decio.nd.edu!jonathan Sat Aug  1 16:26:06 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "09:42:56" "-0700" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " nil "7" "LambdaCore anyone?" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 16:26:02 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11576>; Sat, 1 Aug 1992 15:49:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11880>; Sat, 1 Aug 1992 15:47:47 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Sat, 1 Aug 1992 15:43:54 -0700
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <11937>; Sat, 1 Aug 1992 09:43:51 PDT
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00811; Sat, 1 Aug 92 11:42:56 EST
X-NS-Transport-ID: 08002008D0FD0020F26F
Message-ID: <9208011642.AA00811@nova.decio.nd.edu>
Date:	Sat, 1 Aug 1992 09:42:56 -0700
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	moo-cows@parc.xerox.com
Subject: LambdaCore anyone?


Whats the chance of getting a LambdaCore dump more recent than 1991?

I've got the core on the FTP site and will port the new core stuff by hand
but I'd rather not reinvent the wheel.

- Jonathan Bradshaw

From netcom.com!frankc Sat Aug  1 17:10:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "17:05:53" "-0700" "Frank Crowell" "frankc@netcom.com " nil "13" "Re: ChaosMOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 17:10:20 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11889>; Sat, 1 Aug 1992 17:09:13 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11884>; Sat, 1 Aug 1992 17:07:40 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Sat, 1 Aug 1992 17:06:43 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11538>; Sat, 1 Aug 1992 17:06:14 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA18836; Sat, 1 Aug 92 17:05:54 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0020F2E2
In-Reply-to: "<9208012114.AA09071@cheetah.math.oxy.edu>; from \"t_pascal@cheetah.math.oxy.edu\" at Aug 1, 92 2:14 pm"
Message-ID: <9208020005.AA18836@netcom.netcom.com>
Date:	Sat, 1 Aug 1992 17:05:53 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Re: ChaosMOO

I appreciate T. Pascal offering a Laboratory site.
At first, I was apprehensive about creating wizards at login.
Then i remember that TMI (The Mud Institute) does that will little fear
and still continues to do it even though it was destroyed last spring.
So, maybe this is the best way: no control, no secret handshake; let's
see what happens.

I will probably be visiting the site soon, hope I see some other
people there.

-- 
Frank Crowell frankc@netcom.COM
Netcom - Online Communication Services San Jose, CA

From netcom.com!frankc Sat Aug  1 19:15:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "1" "August" "1992" "19:08:57" "-0700" "Frank Crowell" "frankc@netcom.com " nil "14" "Re: MOO Institute" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 19:14:57 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11888>; Sat, 1 Aug 1992 19:13:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11887>; Sat, 1 Aug 1992 19:11:39 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 1 Aug 1992 19:09:59 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11888>; Sat, 1 Aug 1992 19:09:18 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA00663; Sat, 1 Aug 92 19:08:58 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0020F338
Message-ID: <9208020208.AA00663@netcom.netcom.com>
Date:	Sat, 1 Aug 1992 19:08:57 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Re: MOO Institute

 
 I think FMPL or CoolMUD could be used mostly by people that want to do
 heavy hacking on the server and database.  But right now, it 
 would take a lot of work to just have a basic system up and running.
 
 The MOO environment is ready-to-go; it would allow some ideas to be 
 implemented; and it could serve as an information interchange. 
 As for the MOO Institute, I could imagine a SIG CoolMUD or
 SIG FMPL.
 
 -- 
 Frank Crowell frankc@netcom.COM
 Netcom - Online Communication Services San Jose, CA
 

From nova.decio.nd.edu!jonathan Sun Aug  2 06:17:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "2" "August" "1992" "06:11:53" "-0700" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " nil "7" "LambdaCore Dump 92?" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sun, 2 Aug 1992 06:17:26 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11929>; Sun, 2 Aug 1992 06:16:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11927>; Sun, 2 Aug 1992 06:15:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 2 Aug 1992 06:13:02 -0700
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <11886>; Sun, 2 Aug 1992 06:12:47 PDT
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01105; Sun, 2 Aug 92 08:11:53 EST
X-NS-Transport-ID: 08002008D0FD0020F4D4
Message-ID: <9208021311.AA01105@nova.decio.nd.edu>
Date:	Sun, 2 Aug 1992 06:11:53 -0700
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	moo-cows@parc.xerox.com
Subject: LambdaCore Dump 92?


(This appeared to bounce - I hope this is not a dupe)

Is there a more recent Lambda core than 1991?  Not that I want to reinvent the
wheel or @dump forever (grin).

- Jonathan

From theory.cs.mankato.msus.edu!nop Sun Aug  2 09:36:26 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "2" "August" "1992" "09:30:52" "-0700" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "10" "MOO Institute" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sun, 2 Aug 1992 09:36:20 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11934>; Sun, 2 Aug 1992 09:35:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11933>; Sun, 2 Aug 1992 09:34:16 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 2 Aug 1992 09:31:37 -0700
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11932>; Sun, 2 Aug 1992 09:31:08 PDT
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA21957; Sun, 2 Aug 92 11:30:52 -0500
X-NS-Transport-ID: 08002008D0FD0020F567
In-Reply-to: "Frank Crowell's message of Sat, 1 Aug 1992 19:08:57 PDT <9208020208.AA00663@netcom.netcom.com>"
Message-ID: <9208021630.AA21957@theory.cs.mankato.msus.edu>
Date:	Sun, 2 Aug 1992 09:30:52 -0700
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	frankc@netcom.com
cc:	moo-cows@parc.xerox.com
Subject: MOO Institute

FMPL is unsuitable for many-programmer MUDs due to its utter lack of
security.  In fact, I'm not sure it's suitable for even
multi-programmer MUDs, since it's so easy to blow away other people's
work.  COOL, on the other hand, has such security, but until recently
could not be used for many-programmer MUDs due to its lack of
unparsing.  After a cursory glance at 1.1, I'm not sure I'd want to
work with it either because the programming facilities seem to want
you to use the C preprocessor heavily.

--Jonny

From unipress.com!joe Sun Aug  2 16:23:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "2" "August" "1992" "16:17:35" "-0700" "joe@unipress.com" "joe@unipress.com" nil "51" "COOLMUD review" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sun, 2 Aug 1992 16:23:08 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11948>; Sun, 2 Aug 1992 16:22:32 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11946>; Sun, 2 Aug 1992 16:20:02 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 2 Aug 1992 16:18:33 -0700
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <11943>; Sun, 2 Aug 1992 16:17:57 PDT
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA14959; Sun, 2 Aug 92 19:17:46 EDT
Received: from dot.UniPress.COM by repo.unipress.com (4.1/SMI-4.1/UniPress121291.1)
	id AA21670; Sun, 2 Aug 92 19:17:41 EDT via
X-NS-Transport-ID: 08002008D0FD0020F6A0
In-Reply-to: "Your message of \"Sun, 02 Aug 92 09:30:52 PDT.\"
             <9208021630.AA21957@theory.cs.mankato.msus.edu>peo"
Message-ID: <9208022317.AA21670@repo.unipress.com>
Date:	Sun, 2 Aug 1992 16:17:35 -0700
From:	joe@unipress.com
To:	moo-cows@parc.xerox.com
Subject: COOLMUD review


I've taken a reasonably close look at COOLMUD, and corresponded with its
author about it a little.  I like it a lot, it has plenty of promise, but it
still has some problems which make it unviable for A many-programmer MUD.

> COOL, on the other hand, has such security, but until recently could not be
> used for many-programmer MUDs due to its lack of unparsing.  After a cursory
> glance at 1.1, I'm not sure I'd want to work with it either because the
> programming facilities seem to want you to use the C preprocessor heavily.

1.1.1 does have 'unparsing'.  It also is designed for use with cpp, which
makes the unparsing a little wierd.

There are two chief problems I have with it;

1) There is no easy way for a wizard to gain access to anything in the DB. 
This is because wizards simply have the power to reprogram any method on any
object in their local database -- so to check something, some reprogramming
must be done by the wizard.  A nefarious player/programmer could lock
information away from a wizard in such a way that it would take a good deal of
work for said Wiz to access it.

2) The security system isn't as advanced as would be needed (IMHO).  For
example, there is no way for a player to allow eirself to be moved from room
to room by exits, while at the same time preventing others from @teleport ing
them around.  The difficulty is that there is no way of telling what chain of
methods led to yours getting called (you only know the caller, not the
callers).

COOLMUD does offer MI and a distributed DB.  Objects cannot have parents from
a foreign COOLMUD database, however.  Hence, the problem with LambdaMOO
"having all the cool stuff" would still exist were it a COOLMUD.  Further,
according to the author, the connections for the distributed database are not
really suitable for 'long-haul' networks.  The database for COOLMUD is still
stored in core, and it has no garbage collector other than a simple
copy-on-reference policy (two problems which plague MOO).

The command parser is a method on the player, which is a very welcome change
from the server-wired command parser in MOO.  Name/object matching is also
accomplished without help from the server.  COOLMUD's language is a refinement
of the MOO language (although I'd still prefer LISP) with some refreshing
changes (verbs and methods are separate, variables have type, etc.).

Anybody interested in server hacking on MUDs of any sort will gain by taking a
careful look at COOLMUD 1.1.1.  You can get it, along with some cursory, out
of date (when I got it) documentation via anonymous ftp from piggy.ucsb.edu.

SRI SYADASTI SYADAVAKTAVYA SYADASTI SYANNASTI SYADASTI CAVAKTAVYASCA
SYADASTI SYANNASTI SYADAVATAVYASCA SYADASTI SYANNASTI SYADAVAKTAVYASCA

-K*

From xerox.com!parc.xerox.com.PARC Sun Aug  2 16:39:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "2" "August" "1992" "16:34:00" "-0700" "Winthrop D Chan" "wdc50@duts.ccc.amdahl.com " nil "8" "Re: CoolMUD" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sun, 2 Aug 1992 16:39:39 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11948>; Sun, 2 Aug 1992 16:38:33 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11947>; Sun, 2 Aug 1992 16:36:53 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 2 Aug 1992 16:35:20 -0700
Received: from charon.amdahl.com ([129.212.11.1]) by alpha.xerox.com with SMTP id <11943>; Sun, 2 Aug 1992 16:34:44 PDT
Received: from amdahl.uts.amdahl.com (sde-hy.uts.amdahl.com) by charon.amdahl.com (4.0/SMI-4.1/DNS)
	id AA17019; Sun, 2 Aug 92 16:34:43 PDT
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.11)
	id <m0mEpRp-00017pC@amdahl.uts.amdahl.com>; Sun, 2 Aug 92 16:34 PDT
Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6)
	id <m0mEpQb-0000iJC@juts.ccc.amdahl.com>; Sun, 2 Aug 92 16:33 PDT
Received: by DUTS.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.7)
	id <m0mEpRA-0000VrC@DUTS.ccc.amdahl.com>; Sun, 2 Aug 92 16:34 PDT
X-NS-Transport-ID: 08002008D0FD0020F6AD
Message-ID: <m0mEpRA-0000VrC@DUTS.ccc.amdahl.com>
Date:	Sun, 2 Aug 1992 16:34:00 -0700
From:	wdc50@duts.ccc.amdahl.com (Winthrop D Chan)
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: Re: CoolMUD

Just as an addendum to the current discussion. I was just on piggy.ucsb.edu to
grab my own copy of CoolMUD to look at, and there is a new version in the
incoming directory (/pub/mud/incoming). coolmud 1.1.2 along with docs v1.0 (as
opposed to v0.9)

Cheers
Winthrop Chan
Avid user of "Thera-Putty"

From media-lab.media.mit.edu!asb Mon Aug  3 06:53:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "06:42:17" "-0700" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "17" "Re: Inter-MOO communication II" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 3 Aug 1992 06:53:49 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11570>; Mon, 3 Aug 1992 06:52:48 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11572>; Mon, 3 Aug 1992 06:48:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 3 Aug 1992 06:42:51 -0700
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11567>; Mon, 3 Aug 1992 06:42:33 PDT
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA09576; Mon, 3 Aug 92 09:42:18 -0400
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD0020FA2A
In-Reply-to: "Your message of \"Sat, 01 Aug 92 09:13:31 PDT.\"
             <9208011613.AA29726@sapphire.cm.cf.ac.uk>"
Message-ID: <9208031342.AA09576@media-lab.mit.edu>
Date:	Mon, 3 Aug 1992 06:42:17 -0700
From:	asb@media-lab.media.mit.edu
To:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
cc:	moo-cows@parc.xerox.com, asb@media-lab.media.mit.edu
Subject: Re: Inter-MOO communication II


I can suggest some interface metaphors that will simplify
the programming task:

How about making each VROOM a tv studio.  In the studio,
you can watch what other MOOStudios are doing, one at a time,
by flipping channels.  An "ON THE AIR" light indicates
whether any other MOO is watching your studio.

If you want to talk to someone in another studio, you can call
them on the telephone.  This simplifies the programming task
and lessens lag problems, because you have to explicity establish 
a connection.  If everyone in two rooms wants to talk, then you
can put it on speaker phone.  If three rooms want to talk,
then you can make a conference call.  :-)

-- Amy

From athos.pei.com!berry Tue Aug  4 16:16:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "09:42:14" "-0700" "Berry Kercheval" "berry@athos.pei.com " nil "16" "Re: Inter-MOO communication II" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 4 Aug 1992 16:16:01 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11827>; Tue, 4 Aug 1992 16:10:03 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11816>; Tue, 4 Aug 1992 16:07:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58400>; Tue, 4 Aug 1992 16:05:50 -0700
Received: from sgi.sgi.com ([192.48.153.1]) by alpha.xerox.com with SMTP id <11583>; Mon, 3 Aug 1992 09:40:11 PDT
Received: from athos.pei.com by sgi.sgi.com via UUCP (920330.SGI/910110.SGI)
	for Moo-cows@parc.xerox.com id AA12774; Mon, 3 Aug 92 09:40:08 -0700
Received: from athos.pei.com by pei.pei.com (5.52/900721.SGI)
	for sgi!parc.xerox.com!Moo-cows id AA06183; Mon, 3 Aug 92 09:40:26 PDT
Received: by athos (4.1/SMI-4.1)
	id AA00877; Mon, 3 Aug 92 09:42:14 PDT
X-NS-Transport-ID: 08002008D0FD0021164F
In-Reply-to: <9208031342.AA09576@media-lab.mit.edu>
Message-ID: <9208031642.AA00877@athos>
References: <9208011613.AA29726@sapphire.cm.cf.ac.uk>
	<9208031342.AA09576@media-lab.mit.edu>
Date:	Mon, 3 Aug 1992 09:42:14 -0700
From:	berry@athos.pei.com (Berry Kercheval)
To:	Moo-cows@parc.xerox.com
Subject: Re: Inter-MOO communication II
Reply-to: berry@pei.com

>>>>> On Mon, 3 Aug 1992 06:42:17 PDT, asb@media-lab.media.mit.edu said:

asb> How about making each VROOM a tv studio.  

Not a bad idea, but how about letting each MOO choose an appropriate
metaphor for their own VROOM?  Ideas might be TV Studio, a room full
of Crystal Balls or Palantiri, a terminal room where players can log
into tinyMOO (the MOO within a MOO), a starship bridge with enormous
viewscreens looking into other VROOMS, and so on.

  --berry

--
Berry Kercheval :: berry@pei.com :: Protocol Engines, Inc.  Mt. View, CA
"And there's more where that came from!"


From elf.com!gub Tue Aug  4 16:16:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "08:34:23" "-0700" "Glen Daniels" "gub@elf.com " nil "13" "Inter-MOO communication II" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 4 Aug 1992 16:16:01 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11795>; Tue, 4 Aug 1992 16:08:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11803>; Tue, 4 Aug 1992 16:05:55 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 4 Aug 1992 16:04:28 -0700
Received: from asylum.sf.ca.us ([192.48.232.17]) by alpha.xerox.com with SMTP id <11571>; Mon, 3 Aug 1992 08:34:27 PDT
Received: by asylum.sf.ca.us 
	id AA03894; Mon,  3 Aug 92 11:34:23 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD00211644
In-Reply-to: "asb@MEDIA-LAB.MEDIA.MIT.EDU's message of Mon, 3 Aug 1992 06:42:17 PDT <9208031342.AA09576@media-lab.mit.edu>"
Message-ID: <9208031534.AA03894@asylum.sf.ca.us>
Date:	Mon, 3 Aug 1992 08:34:23 -0700
From:	gub@elf.com (Glen Daniels)
To:	asb@media-lab.media.mit.edu
cc:	Andrew.Wilson@computing-maths.cardiff.ac.uk, moo-cows@parc.xerox.com
Subject: Inter-MOO communication II


	I like the "TV studios" metaphor.... One of the other little
projects I was thinking about was a room which connects you to IRC -
for you, it appears you are in a room full of people (i.e. "look" will
tell you who's on your IRC channel), and for them, it looks like
you're another IRC user.  Whispers automatically get converted into
/msg's, and when you turn the big dial on the wall (to change
channels), all the people fade out and new ones fade in.  Alternately,
you get in an elevator and whatever floor you choose is the channel
you end up on....

		--Gub (Glen Daniels, gub@elf.com)
	"The future exists first in Will, then Imagination, then Reality."

From netcom.com!frankc Tue Aug  4 16:16:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "15:04:06" "-0700" "Frank Crowell" "frankc@netcom.com " nil "8" "Chaos" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 4 Aug 1992 16:16:00 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11790>; Tue, 4 Aug 1992 16:12:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11805>; Tue, 4 Aug 1992 16:09:19 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58413>; Tue, 4 Aug 1992 16:08:05 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11632>; Mon, 3 Aug 1992 15:04:29 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA10340; Mon, 3 Aug 92 15:04:06 PDT
X-NS-Transport-ID: 08002008D0FD00211658
Message-ID: <9208032204.AA10340@netcom.netcom.com>
Date:	Mon, 3 Aug 1992 15:04:06 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Chaos


Concerning Chaos,

Definitely there should be a bulletin board room.

I would also suggest a central area for hanging out and conversing.
Somewhere off the central would be the the exits to the mad wizards area,
this is to their workshops. 

From computing-maths.cardiff.ac.uk!Andrew.Wilson Tue Aug  4 16:16:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "08:43:15" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "88" "Inter-MOO communication II" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Tue, 4 Aug 1992 16:16:01 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11830>; Tue, 4 Aug 1992 16:11:24 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11833>; Tue, 4 Aug 1992 16:08:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58403>; Tue, 4 Aug 1992 16:07:08 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11580>; Mon, 3 Aug 1992 08:58:36 PDT
Via: uk.ac.cardiff.computing-maths; Mon, 3 Aug 1992 16:43:39 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <00882-0@sentinel.cm.cf.ac.uk>; Mon, 3 Aug 1992 16:43:21 +0100
X-NS-Transport-ID: 08002008D0FD00211656
Message-ID: <9208031543.AA00644@sapphire.cm.cf.ac.uk>
Date:	Mon, 3 Aug 1992 08:43:15 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com, Andrew.Wilson@computing-maths.cardiff.ac.uk
Subject: Inter-MOO communication II


Hi,
	I sent this one to Amy when it should really have gone to
everyone:

---

Hi Amy,

	you say:

>How about making each VROOM a tv studio.  In the studio,
>ou can watch what other MOOStudios are doing, one at a time,
>by flipping channels.  An "ON THE AIR" light indicates
>whether any other MOO is watching your studio.

	A TV Studio eh?  Mmm, well, cool I suppose, but I think that
the amount of programming involved would be greater than for a simple VROOM.
The main problem that I see with VROOMs is the possibility of their being
simply too many people all talking at the same time.  From experience
of places like LambdaMOO I'd say that a VROOM would be unworkable if there
were more than say five people talking at the same time.  This isn't a problem
with VROOMs specifically, the same thing happens now whenever 3 or more chatty
people meet in a room.  It's just that VROOMs by their nature would tend to
have more people in them than normal.  Conventional chat sites get round this
problem by having more than one room for people to go to, so they have somewhere
to go if they DO want a quiet conversation or for reasons of privacy.
	Of course there's nothing to stop you implementing a group of
connected VROOMS.  It's just a matter of each participating MOO having a
topologically (sp?) equivalent area consisting of $rooms which implement
the VROOM code.  If Frederique on GodNet goes north from the first VROOM
she'll move into the second VROOM and, provided that LambdaMOO's got the 
same (V)topology then BigMac will be able to join her again by simply
going north from his own 'first' VROOM on LambdaMOO.
	There is a problem with my idea for implementing VROOMs which
would tend to limit the extent of the Vtopology, that is, that each room
that implements the VROOM code would be linked to it's partners by a network
connection implemented as a VPLAYER.  So for example, if there were 5
participating MOOs, including LambdaMOO as the 'central' VROOM then this
would require 8 connections: 2 for each of the 'outside' MOO sites and 8
for poor old LambdaMOO.  If you add another VROOM to the Vtopology then
this doubles the number of connections required!  Obviously this is a MAJOR
shortcoming in my design.  I think that VROOMs, if their implementation
remains unaltered, will make Vtopologies of more than say 3 VROOMs completely
unworkable.

DOING IT DIFFERENTLY 
	There IS another 'more difficult' implementation strategy which
will reduce the number of connections required dramatically.  Each participating
MOO connects to LambdaMOOs central VROOM using a single connection and
LambdaMOO connects out to the other MOOs.  With 5 sites this means 8 connections
as before.  However, outlying rooms are coded differently, anything 'said'
in an outlying room is caught (by the room's tell verb, or whatever) and
passed to the VPLAYER connections in the central VROOM, together with a 'tag'
indicating its destination in terms of the Vtopology.  The information
is passed to each of the outlying MOO sites and the tag is decoded to 'echo'
the information in the correct VROOM on each site.

	A VROOM is also meant to 'look' like any other room in the MOO so
ideally a simple 'look' would display the contents of the VROOM by deriving
them from the contents of the connected rooms on all the participating
sites.  There IS a significant problem with net-lag to be overcome, and in
addition to this we also need a sensible way of ensuring that we don't
confuse the results of one request for 'look' information to other sites with
results from some other different request.  I'm beginning to get out of my
depth here algorithm-wise but I'll keep at it until someone shouts 'fraud'
or shows me how to do it.

	I think that the room analogy that exists on every MUD in the world
is wonderfully simple and really very efficient, from the user's point of view.
If I was going to seek to complicate the coding of VROOMs then I'd try
to do it at the 'hidden' level described above in 'DOING IT DIFFERENTLY' and
seek my efficiency there rather than present users with another analogy.

There are probably much better ways to do this, I'm just trying to do it with
what little resources we have at hand.

Andrew Wilson.

ps.  Of course you realise that all of the above is simply your MOOStudio
idea with different words.  But I HAD to write all this just to be sure.
A. :-)

---

I never could get the hang of this new-fangled teknollogee stuff anyway!

Andrew.

From senex.unh.edu!unhtel!morwyn!forrie Tue Aug  4 16:21:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "19:26:41" "-0700" "Forrie Aldrich" "forrie@morwyn.uucp" nil "25" "Non-networking MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 4 Aug 1992 16:21:05 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11790>; Tue, 4 Aug 1992 16:15:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11859>; Tue, 4 Aug 1992 16:11:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58419>; Tue, 4 Aug 1992 16:10:32 -0700
Received: from senex.unh.edu ([132.177.128.103]) by alpha.xerox.com with SMTP id <11663>; Mon, 3 Aug 1992 19:26:28 PDT
Received: by senex.unh.edu id AA08241
  (5.65c+/IDA-1.4.4 for parc.xerox.com!moo-cows); Mon, 3 Aug 1992 22:28:33 -0400
Received: by unhtel.unh.edu (smail2.5R)
	id AA28140; 3 Aug 92 22:29:02 EDT (Mon)
Received: by morwyn.UUCP id AA10001
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Mon, 3 Aug 1992 22:26:41 -0400
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
X-NS-Transport-ID: 08002008D0FD00211665
Message-ID: <199208040226.AA10001@morwyn.UUCP>
Date:	Mon, 3 Aug 1992 19:26:41 -0700
From:	Forrie Aldrich <forrie@morwyn.uucp>
Sender: unhtel!morwyn!forrie@senex.unh.edu
To:	moo-cows@parc.xerox.com
Subject: Non-networking MOO

There was some brief speculation/talk earlier about hacking LambdaMOO to
compile and run on a non-networking machine.  The subject was quickly
dropped; however, I'm curious if anything resulted from this or if anyone
has accomplished this task.

I'm desperately trying to get LambdaMOO to compile (and RUN) on my
platform.  Undoubtedly, I will have difficulty considering my networking
library is older and was written (hacked is more appropriate) by the
Wollongong Group.  While the necessary routines are there, it is unlikely
that I will be able to RUN it (if it gets compiled) because I lack an
ethernet board.  You can't do a loopback if you don't have a device that
will loop back the packets...

Anyways, I would really appreciate some help with this... it's very
important to me, and I have been diligently trying for some time to find a
way to accomplish this.

Thanks in advance... any help/advice would be greatly appreciated.

-- 
	   -----------	      Forrest Aldrich	      -----------
	   -------     morwyn!forrie@unhtel.unh.edu	  -------
	   ----						     ----
	   --	     VISION GRAPHICS --	Dover, NH - USA	       --
	   ------------------------------------------------------

From oxy.edu!bdrake Tue Aug  4 16:21:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "3" "August" "1992" "17:30:12" "-0700" "Barry T. Drake" "bdrake@oxy.edu " nil "8" "More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Tue, 4 Aug 1992 16:21:06 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11820>; Tue, 4 Aug 1992 16:14:26 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11844>; Tue, 4 Aug 1992 16:10:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58414>; Tue, 4 Aug 1992 16:09:12 -0700
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <11642>; Mon, 3 Aug 1992 17:29:42 PDT
Received: by gate.oxy.edu (4.0/SMI-4.0)
	id AA11339; Mon, 3 Aug 92 17:30:12 PDT
X-NS-Transport-ID: 08002008D0FD0021165D
Message-ID: <9208040030.AA11339@gate.oxy.edu>
Date:	Mon, 3 Aug 1992 17:30:12 -0700
From:	bdrake@oxy.edu (Barry T. Drake)
To:	moo-cows@parc.xerox.com
Subject: More C-like MOO


Well, I'll probably get chewed for this one, but how about this sticky idea:

Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
I think they are more readable, but perhaps that is only me.  Just an
idea. :)

bdrake

From andrew.cmu.edu!jt1o+ Tue Aug  4 16:21:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "4" "August" "1992" "13:43:23" "-0700" "Moonchilde" "jtraub+@cmu.edu" nil "4" "More on the infinite loop." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Tue, 4 Aug 1992 16:21:06 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11851>; Tue, 4 Aug 1992 16:17:31 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11866>; Tue, 4 Aug 1992 16:12:58 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 4 Aug 1992 16:11:50 -0700
Received: from po2.andrew.cmu.edu ([128.2.249.105]) by alpha.xerox.com with SMTP id <11750>; Tue, 4 Aug 1992 13:44:57 PDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA18036> for moo-cows@parc.xerox.com; Tue, 4 Aug 92 16:44:50 EDT
Received: via switchmail; Tue,  4 Aug 1992 16:44:47 -0400 (EDT)
Received: from freehold.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.UeTijlm00WD51NQU5t>;
          Tue,  4 Aug 1992 16:43:30 -0400 (EDT)
Received: via niftymail; Tue, 4 Aug 1992 16:43:24 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD0021166D
Message-ID: <712961003.22897.0@freehold.andrew.cmu.edu>
Date:	Tue, 4 Aug 1992 13:43:23 -0700
From:	Moonchilde <jtraub+@cmu.edu>
Sender: jt1o+@andrew.cmu.edu
To:	moo-cows@parc.xerox.com
Subject: More on the infinite loop.

The problem is definately occuring inside vardup() when applied to a very
long list.  Why it's dying so completely, I do not know.

--moonchilde

From minos.nmt.edu!schlake Tue Aug  4 17:49:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "4" "August" "1992" "17:45:35" "-0700" "Schlake" "schlake@minos.nmt.edu " nil "23" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 4 Aug 1992 17:49:43 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11842>; Tue, 4 Aug 1992 17:48:13 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11829>; Tue, 4 Aug 1992 17:46:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 4 Aug 1992 17:45:26 -0700
Received: from minos.nmt.edu ([129.138.1.5]) by alpha.xerox.com with SMTP id <11810>; Tue, 4 Aug 1992 17:44:56 PDT
Received: by minos.nmt.edu
	(16.6/15.6) id AA00424; Tue, 4 Aug 92 18:45:36 -0600
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
X-NS-Transport-ID: 08002008D0FD002117C9
In-Reply-to: "bdrake@oxy.edu (Barry T. Drake)
       \"More C-like MOO\" (Aug  3,  5:30pm)"
Message-ID: <9208050045.AA00424@minos.nmt.edu>
Date:	Tue, 4 Aug 1992 17:45:35 -0700
From:	schlake@minos.nmt.edu (Schlake)
To:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO

On Aug 3,  5:30pm, Barry T. Drake wrote:
> Subject: More C-like MOO
>Date: 	Mon, 3 Aug 1992 17:30:12 PDT
>From: bdrake@oxy.edu (Barry T. Drake)
>
>Well, I'll probably get chewed for this one, but how about this sticky idea:
>
>Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
>I think they are more readable, but perhaps that is only me.  Just an
>idea. :)
>
>bdrake
>
}-- End of excerpt from Barry T. Drake

I got a better one.  How about adding in a 'break' statement that takes
an argument of how many control loops to beak out of.

:) :) :) :) (if you don't uderstand the smileys, look at pre-Haakon MOO)



-- void *(*(*schlake())[])(void *);

From theory.cs.mankato.msus.edu!nop Tue Aug  4 22:05:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "4" "August" "1992" "21:59:00" "-0700" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "25" "Non-networking MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 4 Aug 1992 22:04:56 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11818>; Tue, 4 Aug 1992 22:04:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11798>; Tue, 4 Aug 1992 22:01:36 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 4 Aug 1992 21:59:44 -0700
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11818>; Tue, 4 Aug 1992 21:59:14 PDT
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA01243; Tue, 4 Aug 92 23:59:00 -0500
X-NS-Transport-ID: 08002008D0FD00211AC6
In-Reply-to: "Forrie Aldrich's message of Mon, 3 Aug 1992 19:26:41 PDT <199208040226.AA10001@morwyn.UUCP>"
Message-ID: <9208050459.AA01243@theory.cs.mankato.msus.edu>
Date:	Tue, 4 Aug 1992 21:59:00 -0700
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	morwyn!forrie@theory
cc:	moo-cows@parc.xerox.com
Subject: Non-networking MOO

> I'm desperately trying to get LambdaMOO to compile (and RUN) on my
> platform.  Undoubtedly, I will have difficulty considering my networking
> library is older and was written (hacked is more appropriate) by the
> Wollongong Group.  While the necessary routines are there, it is unlikely
> that I will be able to RUN it (if it gets compiled) because I lack an
> ethernet board.  You can't do a loopback if you don't have a device that
> will loop back the packets...

I can't remember if Wally does this for sure, but most TCP/IP
implementations I've seen have a loopback pseudodevice (interface)
that is always there.

What platform is this?  I'd guess SysVr3.[12], but it'll be hard to
help without more specifics.  I suspect the linux version (if there is
one right now) would be a good place to look for non-networking stuff
for Unix systems.

--Jonny

ObRant:  I suffered under the Wollongong Group's software on a 3b2.
To add insult to injury, the telnetd prints "WINS Telnet Service" when
you log in remotely.  If said machine comes under my administrative
control this fall, I'm going to take a binary editor and make it say
"LOSES"...


From magnus.acs.ohio-state.edu!grenner Tue Aug  4 23:29:50 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "4" "August" "1992" "23:23:26" "-0700" "Gavin H Renner" "grenner@magnus.acs.ohio-state.edu" nil "16" "AmigaMOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 4 Aug 1992 23:29:45 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11715>; Tue, 4 Aug 1992 23:28:13 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11809>; Tue, 4 Aug 1992 23:26:10 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 4 Aug 1992 23:24:13 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11715>; Tue, 4 Aug 1992 23:23:53 PDT
Received: from bottom.magnus.acs.ohio-state.edu ([128.146.216.14]) by alpha.xerox.com with SMTP id <11810>; Tue, 4 Aug 1992 23:23:27 PDT
Received: by bottom.magnus.acs.ohio-state.edu (5.65/3.910213)
	id AA06096; Wed, 5 Aug 92 02:23:26 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00211B92
Message-ID: <9208050623.AA06096@bottom.magnus.acs.ohio-state.edu>
Date:	Tue, 4 Aug 1992 23:23:26 -0700
From:	Gavin H Renner <grenner@magnus.acs.ohio-state.edu>
To:	MOO-Cows.PARC@xerox.com
Subject: AmigaMOO

Hello.. I have recently been looking through the FTP station there and I came 
accross something that looked very interesting...  AmigaMOO... Sense I have an 
affection for MOO and an Amiga I thought it might be an intriguing concept to 
grab it and create my own little world in my home.  But, after I FTP'd the file
to my directory and Xmodem'd it home I then tried to UnArchive the file.. It 
got an error right at the end file.. some ReadMe file I think.. but It would 
not work without it.. Not sure if that little error was the problem or not, due
to the fact that it told me something like 'need at least Version 37 of Ixemul'
whatever that is.. I dunno exactically, but I would like to find out who 
created the AmigaMOO.lzh file and also would like to know when/if it would be 
finished and then I could grab it and Make my own MOO...

Just Curious, Leave me a line at this adress or leave MOO mail to Dragonslayer,
the later being the more favorable.  I thank you for your time..

Dragonslayer

From computing-maths.cardiff.ac.uk!Andrew.Wilson Wed Aug  5 06:10:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "5" "August" "1992" "05:44:26" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "99" "Inter-MOO communication III" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 5 Aug 1992 06:10:50 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11888>; Wed, 5 Aug 1992 06:09:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11875>; Wed, 5 Aug 1992 06:07:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 5 Aug 1992 06:05:05 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11894>; Wed, 5 Aug 1992 06:04:40 PDT
Via: uk.ac.cardiff.computing-maths; Wed, 5 Aug 1992 13:45:04 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <27438-0@sentinel.cm.cf.ac.uk>; Wed, 5 Aug 1992 13:44:38 +0100
X-NS-Transport-ID: 08002008D0FD00211E9A
Message-ID: <9208051244.AA17674@turquoise.cm.cf.ac.uk>
Date:	Wed, 5 Aug 1992 05:44:26 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com
Subject: Inter-MOO communication III


Hi,

berry@athos.pei.com (Berry Kercheval) says:

>asb> How about making each VROOM a tv studio.  

>Not a bad idea, but how about letting each MOO choose an appropriate
>metaphor for their own VROOM?  Ideas might be TV Studio, a room full
>>of Crystal Balls or Palantiri, a terminal room where players can log
>into tinyMOO (the MOO within a MOO), a starship bridge with enormous
>viewscreens looking into other VROOMS, and so on.

Ok, it's good but we'll have to start thrashing out the details pretty soon.
Like:
	1) How do we connect MOO sites and pass information back and
	forth between MOOs.  We could use VPLAYERs because that approach
	would require the least amount of hacking of either LamdaCore
	or the MOO server.  Alternatively we could use something like the
	'remotemoo:eval("moocode")' command [daum@ee.ualberta.ca (Ryan Daum)].

	2) Do we have a Vtopology with more than one VROOM (a bit complicated),
	or do we just have a single VROOM (easier to code, but less fun).

	3) What features should VROOMs have?  We should be able to 'say',
	'tell', 'whisper' and 'look' and have some mechanism to allow us
	to access information for these commands from the other connected
	MOOs.  What other features should VROOMs have?  VBOARDS perhaps?
	And if we're going to have a different analogy to the VROOM on each
	site (Studios, a Starship bridge, ordinary boring old rooms etc.)
	then how do we make the commands that one anaolgy recognises have
	a meaning in another analogy?

	4) (Yuk!)  What protocol do we use for passing messages between MOOs?
	Suppose we all implement a Vtopology, what it looks like on your
	own site is up to you of course, but the general idea is that there'd
	be more than one VROOM.  If Frederique says 'Hello.' in VROOM1 on GodNet
	then the occupants of all rooms connected to VROOM1 on all the other
	sites should be able to hear this, if your site's VROOM implementation
	permits this.

	GodNet would probably have to transmit something like:

		<ALL GodNet SAY VROOM1 Frederique 'Hello.'>

	the format's just made up but means roughly:

		To: ALL connected MOOs.
		From: GodNet
		Event Type: SAY
		Event Location: VROOM1
		Event First Parameter: Frederique
		Event Second Parameter: 'Hello'

	with that sort of information available any VROOM implementation
	should be able to do something useful.  Eventually, down in
	LambdaMOO's VROOM1, BigMac should 'hear':

		Frederique says, 'Hello.'

	This is just an example, what would the other 'messages' look like
	for commands like 'whisper' and 'look'.  Remember that 'whisper'
	will have to check that the person you're 'whispering' to is present
	in the same VROOM as you.  A command like 'look' will, at the very
	least have to request a list of other player's names from
	each MOO.

	For example, Frederique on GodNet types 'look'.  GodNet would send
	the message:

		<ALL GodNet REQUEST_PLAYER_NAMES VROOM1 26341>

	meaning:

		To: ALL connected MOOs
		From: GodNet
		Event Type: REQUEST_PLAYER_NAMES (send a list of the names
		of the players who're in this VROOM on your site).
		Event Location: VROOM1
		Event First Parameter: 26341 (Tag the returned information
		with this label so that GodNet knows which requesting
		verb to give the information to).

	and then the results would be returned from the other sites
	and collated by the 'look' verb.  So GodNet might recieve:

		<GodNet LamdaMOO DATA_PACKET 26341 BigMac yduJ Haakon>
		<GodNet DalMOO DAtA_PACKET 26341 Sammy>

	and would recognise the label 26341 on the data and be able to
	build a meaningful response for Frederique:

		This is one of the many VROOMs in the MOOniverse.
		Beware!  People are not what they seem.
		BigMac, yduJ, Haakon and Sammy are here.

	5)  What other ways are there of doing this?

Andrew Wilson

From ee.ualberta.ca!daum Wed Aug  5 11:18:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "5" "August" "1992" "11:07:39" "-0700" "Ryan Daum" "daum@ee.ualberta.ca" nil "133" "MOO communication" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 5 Aug 1992 11:18:07 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11951>; Wed, 5 Aug 1992 11:16:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11935>; Wed, 5 Aug 1992 11:13:06 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 5 Aug 1992 11:09:19 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11925>; Wed, 5 Aug 1992 11:08:56 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11935>; Wed, 5 Aug 1992 11:08:07 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA16850; Wed, 5 Aug 92 12:07:41 -0600
Full-Name: Ryan Daum
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD002123A4
Message-ID: <92Aug5.110807pdt.11935@alpha.xerox.com>
Date:	Wed, 5 Aug 1992 11:07:39 -0700
From:	Ryan Daum <daum@ee.ualberta.ca>
To:	moo-cows.PARC@xerox.com
Subject: MOO communication

MOO Distribution

	Experiences and ideas for effective MOO database distribution.
	

	JoeFeedback and a few others have seen the results of my
experiments with MOO distribution, but most seem to be unfamiliar with
them so I will describe what I did and perhaps release the objects in
question to beta.xerox.com in the contrib/moocode directory in a few
weeks in some better form.

	What I have here is remote MOO evaluation of code.  All these
VROOM proposals I've seen disgust me because they are limiting the types
of objects and the nature of the objects that can pass through the
virtual room.  That is, they do not sit at a low enough level and cannot
handle the interesting elements which MOO is useful for: database
changes, new types of rooms, new types of player classes, etc. which may
break the VROOM idea.

	What I had in mind was something that sat at a much lower level,
and that was remote MOO evaluation of code.

	What I implemented, ran, and used, for a week or so, was this:
	
	On my local MOO:
	
		Network Room:	A room which contains a variety of relaying
				devices.
				
			Contents:
				LambdaMOO Relay Device (#85)
				
	On LambdaMOO
	
		Player Entarte_Welt:	A player who's sole purpose is to
					retrieve evaluations from LambdaMOO
					via Everyman:eval.
					
	A session would start like this:
	
		@start #85
		LambdaMOO Relay Device connected to lambda.parc.xerox.com 8888
		Player logged in.
	
	From that moment on typing:
	
		;#85:eval("4+4")
		
	Would send ;4+4 to LambdaMOO.
	
	The advantage is that because we are able to execute and
evaluate code on a remote MOO, we can actually attempt to distribute
objects by playing nice tricks with :* verbs and such.  Of course, this
approach has huge problems, and I never sorted out how I would do the
actual distribution, but it certainly aids and adds to the usefullness
of any sort of distribution.

	Now comes the ugly part.
	
	My first problem lay in the way open_network_connection works. 
Instead of just opening the connection and reading the lines one by one
as they come, one has to set up a seperate task which filters (weeds)
its way through the text and does stuff with it, and another seperate
task to send.  By seperating the two, one has the problem of not knowing
which returned values represent which eval statement.  The read and
write processes are out of sync, and there is no real solution for this
other than marking every returned value with a unique identification
stamp -- which is what I am now attempting to do.

	The second problem is lag.  Not only have I no idea which
returned values represent which eval statement, but lag utterly screws
up any timing.  If I send eval("4+4") I have no way of knowing when the
result is going to come, so the best I can do is guess and put a suspend
for a huge amount of time in my get_returned_value loop.  This, of
course, reduces speed by a huge margin, and is often innacurate.  What
would end up happening with me is things like this:

	player:tell(#85:eval("4+4"));
	8
	playeR:tell(#85:eval("#18502:tell(\"hi, Comrade, this is you
speaking from the OTHER SIDE\"));
	8
	player:tell(#85:eval("4+4"));
	0
	
	You get the idea.
	
	Solutions?
	
	My first idea is to hack this system by
	
	a) adding unique ID "stamps" to every item sent to the other MOO.
This would allow some resemblance of sync between read and write.

	b) creating some sort of loop which waits until it knows for
sure that the returned value belongs to it.

	The downside of both of these solutions is that they slow down
the system further, and make it even *more* of a hack.

	There is another solution, but it is beyond my capabilities, and
that is to implement the CoolMUD YO protocol on MOO.

	YO is CoolMUD's method of distributing objects.  It sends
packets which execute verb code on the other side.  CoolMUD is close
enough to MOO that it should not be such a huge deal to port this
protocol to MOO.  All that would be needed would be a simple addition to
handle the #@server notation in the moo code parser and command parser
and modify YO to handle (ugh) properties.

	Instead of just executing code on the other side, YO actually
accomplishes a actual distribution by making the objects available for
use in a traditional manner on both sides of the MOO.  One refers to an
object YO also has its problems.  It is not very efficient
or useful for wide area networks.  Its only real usefullness is in a
small local area network.

	The third solution, as far as I can see, is to implement what I
described above (the remote evaluation via open_network_connection) as
an actual protocol.  The advantage over YO is that it would not use up
so much bandwidth, and would perhaps allow for more creativity.  On the
downside, YO actually does a distribution of objects, whereas my
solution requires extra MOO code to pretend the objects are distributed.

	Big enough message? :-)
	
	Ryan Daum	daum@bode.ee.ualberta	Comrade@LambdaMOO
						Former Archwizard of
							Floodplain and
							a guy with too
							much freedom
							to put MOO
							servers up :-)

From casbah.acns.nwu.edu!hpa Wed Aug  5 11:20:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "5" "August" "1992" "11:12:38" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "12" "LambdaMOO 1.5.20 dumps" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 5 Aug 1992 11:20:25 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11936>; Wed, 5 Aug 1992 11:18:03 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11948>; Wed, 5 Aug 1992 11:15:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Wed, 5 Aug 1992 11:13:13 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11908>; Wed, 5 Aug 1992 11:12:41 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA25571; Wed, 5 Aug 92 13:12:39 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002123BD
Message-ID: <9208051812.AA25571@casbah.acns.nwu.edu>
Date:	Wed, 5 Aug 1992 11:12:38 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: LambdaMOO 1.5.20 dumps
Reply-to: hpa@nwu.edu

HI there,
For some reason it seems like I cannot get the LambdaMOO server to dump at
any other interval than every 20 minutes, despite $dump_interval being set
to 3600.  Anyone else have that problem, or know what to do about it?

	/hpa - Zytor - Xorbon

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
"Kissing a smoker is like licking an ashtray."  -- R. Heinlein

From cheetah.math.oxy.edu!t_pascal Wed Aug  5 22:31:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "5" "August" "1992" "22:17:30" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "31" "Server Crashes" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 5 Aug 1992 22:31:41 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12012>; Wed, 5 Aug 1992 22:30:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12006>; Wed, 5 Aug 1992 22:28:16 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 5 Aug 1992 22:26:39 -0700
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <12005>; Wed, 5 Aug 1992 22:26:13 PDT
Received: from jaguar.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA13220; Wed, 5 Aug 92 22:17:31 PDT
Received: by jaguar.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA08891; Wed, 5 Aug 92 21:17:30 GMT-0800
X-NS-Transport-ID: 08002008D0FD00212E31
Message-ID: <9208060517.AA13220@cheetah.math.oxy.edu>
Date:	Wed, 5 Aug 1992 22:17:30 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	moo-cows@parc.xerox.com
Subject: Server Crashes


The ChaosMOO has crashed twice, in as many days...  I don't blame anyone,
I just wonder if this is a problem with the server, or code in the db.
Information follows:

Server version: 1.5.20
Machine data:   '040 NeXT slab, 25 Mb ram, running mach, OS version 2.1
Compilers:  NeXT Release 2.0 (v31.1) -- GNU version 1.36


I guess that the gnu compiler might be out of date, I can install the newest
one if necessary.  Here are the messages from the log file, it just shuts
down, nothing, no panic dump, no typing-since-last dump, nothing.

Aug  4 16:02:31: *** PANIC: memory allocation (size 222) failed!
Aug  4 16:02:31: *** PANIC: memory allocation (size 100) failed!
Aug  4 16:02:31: *** RECURSIVE PANIC: aborting
Aug  5 11:27:57: *** PANIC: memory allocation (size 26) failed!
Aug  5 11:27:57: *** PANIC: memory allocation (size 100) failed!
Aug  5 11:27:57: *** RECURSIVE PANIC: aborting


Durn, I guess :)


---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
...!gate.oxy.edu!t_pascal t_pascal@{cub.math,jaguar.math,bobcat,tiger}.oxy.edu

From lucifer.interlan.com!billl Thu Aug  6 09:26:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "09:13:39" "-0700" "sweet william" "billl@lucifer.interlan.com " nil "21" "MOO network clients" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Thu, 6 Aug 1992 09:26:03 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11602>; Thu, 6 Aug 1992 09:24:55 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11607>; Thu, 6 Aug 1992 09:21:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Thu, 6 Aug 1992 09:12:53 -0700
Received: from interlan.interlan.com ([130.204.8.1]) by alpha.xerox.com with SMTP id <11602>; Thu, 6 Aug 1992 09:12:22 PDT
Received: from lucifer.InterLan.COM by interlan.interlan.com (5.65/1.35)
	id AA13006; Thu, 6 Aug 92 12:08:11 -0400
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD00213493
Message-ID: <9208061613.AA05241@lucifer.Interlan.COM>
Date:	Thu, 6 Aug 1992 09:13:39 -0700
From:	billl@lucifer.interlan.com (sweet william)
To:	moo-cows@parc.xerox.com
Subject: MOO network clients

I was interested to read Glen Daniels' suggestion about a MOO 
IRC client, and was wondering what the MOO community at large
thought about extending MOOs to talk to outside network sources:
is this a sufficient and viable interface to all the services
the internet can provide?  Will people be interested in going to
the trouble of learning MOO to use its interface to speak out
to the net?
I slant my question given this observation: it seems from the
discussion I have witnessed so far as tho there are people out
there who are toying with ideas to make MOO a 'workplace' for the 
'state of the market' users...those people who wish to use internet
services available NOW in an intuitive and 'no brainer' environment
rather than a cool experimental platform.  
Obviously, the experimentation to make MOO do this has academic value 
for those of us who think that hacking network apps. is fun :)
But is there anyone who will be using this stuff when we are done?
Does anyone care?

Later
dr "@" lambda


From casbah.acns.nwu.edu!hpa Thu Aug  6 11:43:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "11:31:57" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "38" "YO!" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 11:43:34 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11610>; Thu, 6 Aug 1992 11:41:41 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11614>; Thu, 6 Aug 1992 11:38:32 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Thu, 6 Aug 1992 11:32:37 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11640>; Thu, 6 Aug 1992 11:32:00 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA02012; Thu, 6 Aug 92 13:31:58 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00213778
Message-ID: <9208061831.AA02012@casbah.acns.nwu.edu>
Date:	Thu, 6 Aug 1992 11:31:57 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: YO!
Reply-to: hpa@nwu.edu

You write:
> 
> 	There is another solution, but it is beyond my capabilities, and
> that is to implement the CoolMUD YO protocol on MOO.
> 
> 	YO is CoolMUD's method of distributing objects.  It sends
> packets which execute verb code on the other side.  CoolMUD is close
> enough to MOO that it should not be such a huge deal to port this
> protocol to MOO.  All that would be needed would be a simple addition to
> handle the #@server notation in the moo code parser and command parser
> and modify YO to handle (ugh) properties.
> 

I don't know if it is just me, but it seems like any such solution would be
ridiculously expensive in terms of network bandwidth, especially if an
object is inherited across a network link.

Also, if I move across a network boundary, all information about me and my
surroundings will have to flow back and forth across the net.

A binary protocol would maybe help somewhat; if systems are ID'd by a
quantity of 5-10 bits a 32-bit representation of object numbers would still
be feasible.  (10 bits would hold 2 monocase letters, allowing for a
#XX99999 notation).  As I see it, the protocol must be able to handle all
of the fundamental MOO operations; most of it can be done by MOO code
evaluation with the extended syntax; some of it (moving, inheritance across
gateways) may be trickier.  Also, there is a permissions question; is Zytor
(#DA2) a player, programmer or wizard when on LambdaMOO (LA)?  When on
ChaosMOO (CH) where all players are wizards by default?  When on Floodplain
(FP) with an all-programmers default, assuming it was still there?

	/Zytor

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16334 at IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
Have you kissed your Swede today?

From elf.com!gub Thu Aug  6 12:03:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "11:54:23" "-0700" "Glen Daniels" "gub@elf.com " nil "94" "MOO network clients" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 12:03:07 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11626>; Thu, 6 Aug 1992 12:02:20 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11631>; Thu, 6 Aug 1992 12:00:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58399>; Thu, 6 Aug 1992 11:54:57 -0700
Received: from asylum.sf.ca.us ([192.48.232.17]) by alpha.xerox.com with SMTP id <11637>; Thu, 6 Aug 1992 11:54:32 PDT
Received: by asylum.sf.ca.us 
	id AA28677; Thu,  6 Aug 92 14:54:23 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD002137E1
In-Reply-to: "sweet william's message of Thu, 6 Aug 1992 09:13:39 PDT <9208061613.AA05241@lucifer.Interlan.COM>"
Message-ID: <9208061854.AA28677@asylum.sf.ca.us>
Date:	Thu, 6 Aug 1992 11:54:23 -0700
From:	gub@elf.com (Glen Daniels)
To:	billl@lucifer.interlan.com
cc:	moo-cows@parc.xerox.com
Subject: MOO network clients


>is this a sufficient and viable interface to all the services
>the internet can provide?  Will people be interested in going to
>the trouble of learning MOO to use its interface to speak out
>to the net?

	Well, I don't know if MOO (or muds in general) as it stands is
the right interface to use, but I think the "shared virtual
environment" paradigm is a good one.  I would guess people will be
more willing to play with different objects in a simulated world than
to learn lots of heterogeneous command sets for various network
clients.

	I think there are some usability problems with the current
MOO/MUD interface.  One of the biggest seems to me to be the lack of
an easy way to play with objects without trial-and-error or @examine.
It would be nice if there were a simple way to get an object to tell
you "what it can do".

	I think a GUI client could really help here.  Such a client
could ask objects if they have a "@bitmap_appearance", and if so,
throw up a graphical depiction of the object.  Objects which didn't
have a graphic could have a default picture.  You could have a screen
area for your inventory, and drag 'n drop objects from the "room"
window (which, again, could either be graphical or a default picture
with a text description) into your posession, or vice-versa.  You
could have an "exits" menu which would take you from room to room (or
some exits could also be represented graphically and mouse-clickable).

	Now here's the interesting part.  By selecting an object,
you could bring up, say, a menu of verbs that object allows you to
utilize.  Then activate a method by clicking.  This, I think, would
remove a lot of complexity and clunkiness from the interface.

	Heading in this direction does not actually even require a GUI
client per se, just a shift in thinking about interfaces to muds.  The
"text adventure" style of parsing commands just isn't flexible or
friendly enough right now, and it probably won't be until some major
work is done on the natural language front.  But adding the ability to
have a more "cybernetic" interface, without the pretense of "language
parsing", might make mud-style worlds easier to use. [caveat: I'm
coming at this from the perspective of wanting to eventually make
shared-world interfaces useful for everything one might want to do
with computers]  For instance, you might add another command character
"*" which "selects" an object for you in a text-based client, and
another, "/", which executes an option on the currently selected
object, for instance:

You are in the study, a comfortable room with oak paneling.
You see a cast-iron safe here.
>l safe
A fairly ornate specimen, this safe must weigh a ton!  It looks very
secure.  A dial is set between two horses carved on the front.
The safe is closed.
>*safe
			--* cast iron safe *--
	[O]pen safe
	[C]lose safe
	[T]urn the dial <Left/Right> <1-100>
	[S]pin the dial, scrambling it
	--------------
	[H]elp
	[I]nformation about the cast iron safe
[at this point, I can still type regular commands, but any '/' will
refer to the safe, which is now selected.  Also note that there are
other methods I can apply to the safe (look, take) which are not in
the menu; could work this way or not.  There are a lot of ways to do this]
>/I
cast iron safe (#1332) is owned by DrFunky (#324)
Aliases: safe and cast iron safe
[etc...]
>/T left 100
You spin the dial to the left, stopping at 100.
You hear the unmistakeable click of a tumbler sliding home.
>
[You get the idea...]

	The "menu of verbs" idea actually is only the simplest form of
a more general idea of "Object Controls".  In general, objects allow
themselves to be manipulated in a variety of ways - these could be
expressed by concepts such as method-menus, analog controls (dials,
sliders), digital controls, buttons, etc... (sounds like a
window-management system, doesn't it?).  Focusing on an object in a
GUI client could bring up its control set (a dial for the safe might
appear, and a handle for opening/closing it), which your client might
allow you to "tack" to your screen somewhere, so you can use it easily
while changing your focus....

	Just some ideas I've been playing with.  Does this seem like a
reasonable direction to be heading in?  I haven't really spent enough
time exploring yet to be sure....

			--Gub (Glen Daniels, gub@elf.com)
	"The future exists first in Will, then in Imagination, then Reality."

From elf.com!gub Thu Aug  6 12:26:33 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "12:16:53" "-0700" "Glen Daniels" "gub@elf.com " nil "40" "YO!" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 12:26:25 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11677>; Thu, 6 Aug 1992 12:25:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11651>; Thu, 6 Aug 1992 12:21:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58400>; Thu, 6 Aug 1992 12:17:34 -0700
Received: from asylum.sf.ca.us ([192.48.232.17]) by alpha.xerox.com with SMTP id <11640>; Thu, 6 Aug 1992 12:16:58 PDT
Received: by asylum.sf.ca.us 
	id AA29338; Thu,  6 Aug 92 15:16:53 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD0021385D
In-Reply-to: "H. Peter Anvin N9ITP's message of Thu, 6 Aug 1992 11:31:57 PDT <9208061831.AA02012@casbah.acns.nwu.edu>"
Message-ID: <9208061916.AA29338@asylum.sf.ca.us>
Date:	Thu, 6 Aug 1992 12:16:53 -0700
From:	gub@elf.com (Glen Daniels)
To:	hpa@nwu.edu
cc:	moo-cows@parc.xerox.com
Subject: YO!


You write:  (talking about YO)
>I don't know if it is just me, but it seems like any such solution would be
>ridiculously expensive in terms of network bandwidth, especially if an
>object is inherited across a network link.

	Why does everyone seem to think this?  I don't see any reason
why this has to be true.  I would think the main way to avoid the
bandwidth crunch is simply to implement a good caching system!  You
grab the information you need, and store it locally.  The server where
the object "really" lives keeps pointers to all remote copies, so it
can update them if anything important changes.

	Also, compression technology is pretty durned impressive
nowadays (of which I am continually aware as I use my 38.4Kbaud
connection over a normal phone line).  For large data transfers, this
could be utilized to cut the bandwidth again.

>Also, if I move across a network boundary, all information about me and my
>surroundings will have to flow back and forth across the net.

	It's probably not a good idea for you to simply maintain a
single connection to a server, and have all data pumped at you through
there.  If you move, the server should tell your client how to make
another connection to the new server, and perhaps pass both you and it
a unique tag for validation purposes.  Then you maintain the new
connection.  Granted, information needs to pass back and forth between
the servers, but again, it gets cached to minimize the bandwidth.

	As for the permissions question, that's a very interesting can
of worms, and one I'd like to delve into at a later date.  You need a
verifyable identification system, and probably the ability to keep
templates which determine any special features objects get (or lose)
while in particular server-domains.

	** DISCLAIMER : I haven't been MUD/MOO hacking for very long, **
	**		please forgive any obvious brain-damage       **

		--Gub (Glen Daniels, gub@elf.com)
	"The future exists first in Will, then in Imagination, then Reality."

From netcom.com!frankc Thu Aug  6 13:10:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "13:04:02" "-0700" "Frank Crowell" "frankc@netcom.com " nil "22" "Re: MOO network clients" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 13:10:29 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11990>; Thu, 6 Aug 1992 13:08:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11887>; Thu, 6 Aug 1992 13:06:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Thu, 6 Aug 1992 13:05:03 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <12014>; Thu, 6 Aug 1992 13:04:29 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA01515; Thu, 6 Aug 92 13:04:04 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00213947
In-Reply-to: "<9208061854.AA28677@asylum.sf.ca.us>; from \"Glen Daniels\" at Aug 6, 92 11:54 am"
Message-ID: <9208062004.AA01515@netcom.netcom.com>
Date:	Thu, 6 Aug 1992 13:04:02 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Re: MOO network clients

Clients-- the often forgotten partners to the MU*. 

There are some graphical clients out there; and Habitat made
heavy use of a graphical client.  But if MU*s are the ugly brothers
to Virtual World/Virtual Realities researchers, clients seem to be the ugly
brothers to MU*s.  

If someone is really interested in experimenting in this area, consider
taking a programmable client (not tinyfugue) and put some hooks into
your favorite GUI. Then build a few rooms and some objects.
Actually a lot of things can be done without any changes on the server
side; but it would require some pattern matching.

Sometime ago I got a flyer from either Compuserve or Genie proclaiming
the FE (Front End, as they are known there) as the hottest way to
interface into multiuser games. FEs work out reasonable well in
a known universe and can actually reduce the traffic between 
server & client. 

-- 
Frank Crowell frankc@netcom.COM
[This Space for Rent]

From stony-brook.scrc.symbolics.com!yduJ Thu Aug  6 13:22:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "13:15:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "11" "Re: MOO network clients" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 13:22:45 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11604>; Thu, 6 Aug 1992 13:21:06 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11632>; Thu, 6 Aug 1992 13:19:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Thu, 6 Aug 1992 13:14:48 -0700
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11640>; Thu, 6 Aug 1992 13:14:04 PDT
Received: from TRISMEGISTUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1120638; 6 Aug 1992 16:14:47-0400
X-NS-Transport-ID: 08002008D0FD00213989
In-Reply-to: <9208062004.AA01515@netcom.netcom.com>
Message-ID: <19920806201518.9.YDUJ@TRISMEGISTUS.SCRC.Symbolics.COM>
Date:	Thu, 6 Aug 1992 13:15:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	frankc@netcom.com, moo-cows@parc.xerox.com
Subject: Re: MOO network clients

I don't know if it's been advertised here yet, but waffle on LambdaMOO
has built some MOO code support for color coding messages for those
without good client support.  I think you have to be using some PC
running DOS or something, and you change your character map locally so
that tilde (~) gets turned into escape (which MOO won't print), and you
get pages in red, whispers in yellow, etc.  I don't know the details
(not being a PC user and preferring emacs-based interfaces) but I think
waffle has written doc.  Is waffle on this list?  Care to advertise?
This is a little far afield from the original topic, I admit.

						yduJ

From dartmouth.edu!Falryx Thu Aug  6 13:47:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "07:38:44" "-0700" "Falryx@dartmouth.edu" "Falryx@dartmouth.edu" nil "39" "Compiler Errors" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 13:47:16 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11629>; Thu, 6 Aug 1992 13:45:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11604>; Thu, 6 Aug 1992 13:43:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Thu, 6 Aug 1992 13:37:49 -0700
Received: from coos.dartmouth.edu ([129.170.16.50]) by alpha.xerox.com with SMTP id <11600>; Thu, 6 Aug 1992 13:37:31 PDT
Received: by coos.dartmouth.edu (5.57/Ultrix3.0-C)
	id AA02415; Thu, 6 Aug 92 16:37:06 -0400
X-NS-Transport-ID: 08002008D0FD002139F8
Message-ID: <9208062037.AA02415@coos.dartmouth.edu>
Date:	Thu, 6 Aug 1992 07:38:44 -0700
From:	Falryx@dartmouth.edu
To:	moo-cows@parc.xerox.com
Subject: Compiler Errors

        I've been trying to get MOO to compile on a DEC, using Ultrix 4.2.
To 
my (albeit, rather limited) knowledge, I've followed README's and Makefile
prompts etc. correctly, signaling the 'more vanilla' compiler that is more
appropriate for my system.

The error is:

% make
cc -g -Dconst= -DUSE_RANDOM -DUSE_POSIX -DBUGGY_STDARG -c bf_prop.c
ccom: Error: bf_prop.c, line 180: no automatic aggregate initialization
          Var           value = arglist.v.list[3];
      ------------------------^
ccom: Error: bf_prop.c, line 180: assignment of different structures
          Var           value = arglist.v.list[3];
      -------------------------------------------^
*** Error code 1

Stop.

I'm mostly confused because not more than two months ago, I'd compiled MOO
without a hitch -- I was estatic 'cuz it was the first M* of any sort that
compiled w/o warnings and/or errors. This is the latest version of MOO
available on parcftp, 1.5.20.

Any ideas?
Falryx (or some derivative thereof @ wherever)

----------------------------------------------------------------------------
--
"I don't know about anyone else,     | "Childhood is short, and maturity
lasts
but >I< came from my room, I'm a     | forever." - Calvin and Hobbes.
kid with big plans, and I'm going    | 
outside!!!" - Calvin & Hobbes        | "The world is a complicated
place..."
----------------------------------------------------------------------------
--


From netcom.com!frankc Thu Aug  6 14:13:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "14:02:59" "-0700" "Frank Crowell" "frankc@netcom.com " nil "28" "Re: MOO network clients" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 14:13:32 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11641>; Thu, 6 Aug 1992 14:12:22 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11634>; Thu, 6 Aug 1992 14:11:06 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Thu, 6 Aug 1992 14:03:52 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11624>; Thu, 6 Aug 1992 14:03:23 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA12319; Thu, 6 Aug 92 14:03:00 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00213A7B
In-Reply-to: "<19920806201518.9.YDUJ@TRISMEGISTUS.SCRC.Symbolics.COM>; from \"Judy Anderson\" at Aug 6, 92 4:15 pm"
Message-ID: <9208062103.AA12319@netcom.netcom.com>
Date:	Thu, 6 Aug 1992 14:02:59 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Re: MOO network clients

Actually yduJ really presents what is holding up
any extensions that require better clients: writing to the common (lowest)
interface.  The other day, I was on some mud, and someone asked
me if i could see the rainbow.  I didn't know what he was talking
about.  Apparently there was some text changing colors; possibly
a cute idea; I'll never know, since my terminal is monochrome (amber on black).
Another example, PMF (clients) allows certain pre-packaged sounds;
I don't know what those sounds are since I don't have sparcstation.

Now I suppose I could have changed to my color system with the 
soundblaster, but I still wouldn't be able to hear the PMF sounds.

Common interface: writing to the common interface may not be as
silly as it seems. Practically every terminal maker, computer system
maker provides vt100/220 emulation. In the 80s many of us wasted
our life away playing rogue. Didn't you just hate 'R' at about
level 8? There are a lot of things that could be played with
just using the escape sequences. 

Standard and Enhanced interface: a better way is to write to standard
interface and require that the clients do their best. Then I would
add the Enhanced level and require that the enhanced clients
conform to this level. This is routinely done in the computer
graphics world.

-- 
Frank Crowell frankc@netcom.COM
[This Space for Rent]

From xerox.com!parc.xerox.com.PARC Thu Aug  6 15:45:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "15:37:13" "-0700" "Ray Nawara cs367-fall91" "rnawara@tusol.cs.trinity.edu " nil "7" "Server errors..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Thu, 6 Aug 1992 15:45:38 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11677>; Thu, 6 Aug 1992 15:44:46 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11616>; Thu, 6 Aug 1992 15:42:16 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Thu, 6 Aug 1992 15:37:00 -0700
Received: from VM1.TUCC.TRINITY.EDU ([131.194.130.1]) by alpha.xerox.com with SMTP id <11933>; Thu, 6 Aug 1992 15:36:21 PDT
Received: from tusol.cs.trinity.edu by VM1.TUCC.TRINITY.EDU (IBM VM SMTP V2R1)
   with TCP; Thu, 06 Aug 92 17:35:04 CDT
Received: from pluto.cs.trinity.edu.cs.trinity.edu by tusol.cs.trinity.edu (4.1/SMI-4.0)
	id AA02172; Thu, 6 Aug 92 17:37:14 CDT
X-NS-Transport-ID: 08002008D0FD00213C2B
Message-ID: <9208062237.AA02172@tusol.cs.trinity.edu>
Date:	Thu, 6 Aug 1992 15:37:13 -0700
From:	rnawara@tusol.cs.trinity.edu (Ray Nawara cs367-fall91)
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: Server errors...

After sucessfully compiling, i ran the 1.5.20 server
, wich i guess was sucessful (im not sure what to look for)
then i tried to cunnect, which gave me the error "operation not supportd on
socket" for the command "setting network connection non-blocking"
this, id guess, means that a socket command is using the wrong syntax...
(oh im on sun 3 running sunos4.1.1) does anyone know off hand whats wrong?
	Ray Nawara (Ash on LambdaMOO)

From andrew.cmu.edu!jt1o+ Sat Aug  1 19:18:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil t nil nil]
	[nil "Sat" "1" "August" "1992" "19:08:17" "-0700" "Moonchilde" "jtraub+@cmu.edu" "<712721297.5462.0@circe.weh.andrew.cmu.edu>" "40" "A bug that made the server infinite loop" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 1 Aug 1992 19:18:27 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11888>; Sat, 1 Aug 1992 19:17:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11889>; Sat, 1 Aug 1992 19:16:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Sat, 1 Aug 1992 19:11:50 -0700
Received: from po5.andrew.cmu.edu ([128.2.10.105]) by alpha.xerox.com with SMTP id <11878>; Sat, 1 Aug 1992 19:10:33 PDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA26760> for moo-cows@parc.xerox.com; Sat, 1 Aug 92 22:10:29 EDT
Received: via switchmail; Sat,  1 Aug 1992 22:10:28 -0400 (EDT)
Received: from circe.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.4eSoCWa00VoxIJLE4D>;
          Sat,  1 Aug 1992 22:08:35 -0400 (EDT)
Received: via niftymail; Sat, 1 Aug 1992 22:08:20 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD0020F33C
Message-ID: <712721297.5462.0@circe.weh.andrew.cmu.edu>
Date:	Sat, 1 Aug 1992 19:08:17 -0700
From:	Moonchilde <jtraub+@cmu.edu>
Sender: jt1o+@andrew.cmu.edu
To:	moo-cows@parc.xerox.com
Subject: A bug that made the server infinite loop

While playing with the core db code I came upon something interestiing.
It involves the seq_utils code as distributed in the LambdaCore db.
Here is what I did to get it to go boom.

;$seq_utils:complement($seq_utils:from_sorted_list({1,3,5,6,7,8,10,11}))
=>  {-2147483648, 1, 2, 3, 4, 5, 9, 10, 12}
;$seq_utils:size({-2147483648, 1, 2, 3, 4, 5, 9, 10, 12})
=>  -8
;$seq_utils:tolist({-2147483648, 1, 2, 3, 4, 5, 9, 10, 12})
-----> infinite loop.
(here's the PS aux output from the machine I'm running on.  Ignore the memory
sizes, MACH's memory tracking on process size is broken)
jtraub   16490  70.2  7.235.4M2.30M p4 RW   12:51 ./moo MoonMOO.db MoonMOO.db.n
--------
>From an initial run through the debugger, it looks like the code is trying
to grow a list to infinite size.  Unfortunately, I haven't looked through the
code enough to track it down more precisely.. I will try to do so.


-------
Here is the code for $seq_utils:tolist (just in case it's different)
-------------------------------------------
seq = args[1];
if (!seq)
  return {};
else
  if (length(seq) % 2)
    seq = {@seq, this.maxneg};
  endif
  l = {};
  for i in [1..length(seq) / 2]
    for j in [seq[2 * i - 1]..seq[2 * i] - 1]
      l = {@l, j};
    endfor
  endfor
  return l;
endif


--Moonchilde

From repo.unipress.com!joe Thu Aug  6 17:11:45 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "14:08:21" "-0700" "joe@repo.unipress.com" "joe@repo.unipress.com" nil "71" "Re: YO!" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 17:11:36 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12025>; Thu, 6 Aug 1992 17:10:57 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11672>; Thu, 6 Aug 1992 17:08:30 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Thu, 6 Aug 1992 16:59:15 -0700
Received: from rutgers.edu ([128.6.21.9]) by alpha.xerox.com with SMTP id <12016>; Thu, 6 Aug 1992 16:58:46 PDT
Received: from repo.unipress.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with UUCP 
	id AA23264; Thu, 6 Aug 92 17:59:53 EDT
Received: from dot.unipress.com by repo.unipress.com (4.1/SMI-4.1/UniPress121291.1)
	id AA03992; Thu, 6 Aug 92 17:25:06 EDT via
X-NS-Transport-ID: 08002008D0FD00213D89
In-Reply-to: "Your message of \"Thu, 06 Aug 92 12:16:53 PDT.\"
             <9208061916.AA29338@asylum.sf.ca.us>proble"
Message-ID: <9208062125.AA03992@repo.unipress.com>
Date:	Thu, 6 Aug 1992 14:08:21 -0700
From:	joe@repo.unipress.com
To:	gub@elf.com (Glen Daniels)
cc:	hpa@nwu.edu, moo-cows@parc.xerox.com, joe@repo.unipress.com
Subject: Re: YO!


Random thoughts:

>You write:  (talking about YO)
>>I don't know if it is just me, but it seems like any such solution would be
>>ridiculously expensive in terms of network bandwidth, especially if an
>>object is inherited across a network link.

> Why does everyone seem to think this?  I don't see any reason why this has
> to be true.  I would think the main way to avoid the bandwidth crunch is
> simply to implement a good caching system!  You grab the information you
> need, and store it locally.  The server where the object "really" lives
> keeps pointers to all remote copies, so it can update them if anything
> important changes.

All too true.  Distributed database solutions certainly exist.  YO doesn't
cache, and that's a big problem.  Nobody has had the gumption or spare time to
address this yet since current MUD server technology needs to be expanded in
othter directions first.  MOO, COOL, et. al. are still in their adolescence. 
Last I heard, Haakon was going to address some of these other problems this
summer, but I can't speak for him.

One problem that caching brings up is concurrent access -- yucko ptewy.  The
way in which MOO schedules threads sort of sweeps this problem under the rug,
since 'critical sections' are implicit, but in a distributed environment there
is no similar easy way (unless only one server evaled and the rest were mere
database servers ... hmm).  I'm not too sure about this, but COOL seems to
have some sort of locking mechansim to handle this (it has a lock() primitive).

>>Also, if I move across a network boundary, all information about me and my
>>surroundings will have to flow back and forth across the net.

> It's probably not a good idea for you to simply maintain a single connection
> to a server, and have all data pumped at you through there.  If you move,
> the server should tell your client how to make another connection to the new
> server, and perhaps pass both you and it a unique tag for validation
> purposes.  Then you maintain the new connection.  Granted, information needs
> to pass back and forth between the servers, but again, it gets cached to
> minimize the bandwidth.

The most primitive attempt at this was the TinyTalk client which responded to
messages like '#### please reconnect to NUKEMUD ####'.  Nefarious players
included messages like these in their descriptions ...  TinyTalk let you
maintain a list of MUDs with your names and passwords on each, so you would
automagically login to the new mud.  Some versions of the GNU Emacs MUD client
might be able to do this too.

I don't think this is the right approach.  I mean, if you're going to cache db
objects in the first place, than the stuff surrounding the player will get
cached too.  So what if the room you and I are in was created on a different
(non-local) MUD?  All of the processing for our communication would be
accomplished by the local server anyway, so there would be no reason for our
clients to go reconnecting.  If we modify the room, then some inter-server
communication would have to take place, but that's unavoidable even if clients
are forced to reconnect.  The responsibility of the client should be minimized
to the jobs of presentation and fancy input, IMHO.

> As for the permissions question, that's a very interesting can of worms, and
> one I'd like to delve into at a later date.  You need a verifyable
> identification system, and probably the ability to keep templates which
> determine any special features objects get (or lose) while in particular
> server-domains.

I won't pretend to understand this, but I agree that permissions in a
distributed MUD environment is quite the worm can.  I think it can be boiled
down to a system of trusted servers.

SRI SYADASTI SYADAVAKTAVYA SYADASTI SYANNASTI SYADASTI CAVAKTAVYASCA
SYADASTI SYANNASTI SYADAVATAVYASCA SYADASTI SYANNASTI SYADAVAKTAVYASCA

-K*

From parc.xerox.com!pavel Thu Aug  6 18:11:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "17:58:34" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "16" "New LambdaCore.db (FINALLY!)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 18:11:39 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12034>; Thu, 6 Aug 1992 18:09:46 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12023>; Thu, 6 Aug 1992 18:08:15 PDT
Received: by lambda.parc.xerox.com id <58399>; Thu, 6 Aug 1992 17:58:41 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00213E4E
Message-ID: <92Aug6.175841pdt.58399@lambda.parc.xerox.com>
Date:	Thu, 6 Aug 1992 17:58:34 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: New LambdaCore.db (FINALLY!)

I finally found time to work on extracting a new LambdaCore database from
LambdaMOO and, unsurprisingly, it was harder than usual because I had to cope
with 8 months' worth of wizard mistakes, rather than the more common one
month's worth.

(Don't let anyone tell you that core-DB extraction is easy!)

Anyhow, it's finally done and out for FTP from parcftp.xerox.com in

		pub/MOO/LambdaCore-6Aug92.db

Enjoy, and please let me know of any bugs you find and/or LambdaMOO-specific
traces.  I'll try to make new cores more frequently, now that I have a deeper
appreciation of the alternative... :-)

	Pavel/Haakon

From silver.cs.umanitoba.ca!steve Thu Aug  6 18:20:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "18:04:14" "-0700" "Steve Charlton" "steve@silver.cs.umanitoba.ca" nil "5" "Re: Server errors..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 18:20:25 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12038>; Thu, 6 Aug 1992 18:18:28 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12037>; Thu, 6 Aug 1992 18:17:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58400>; Thu, 6 Aug 1992 18:08:22 -0700
Received: from ccu.UManitoba.CA ([130.179.16.8]) by alpha.xerox.com with SMTP id <12039>; Thu, 6 Aug 1992 18:04:12 PDT
Received: from silver.cs.UManitoba.CA by ccu.UManitoba.CA
	(4.1/25-eef) id AA18584; Thu, 6 Aug 92 20:03:12 CDT
Received: from carbon.cs.umanitoba.ca by silver.cs.UManitoba.CA
	(4.1/25-eef) id AA15791; Thu, 6 Aug 92 20:04:25 CDT
Received:  by carbon.cs.umanitoba.ca
	(4.1/25-eef) id AA04200; Thu, 6 Aug 92 20:04:15 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00213E6B
Message-ID: <9208070104.AA04200@carbon.cs.umanitoba.ca>
Date:	Thu, 6 Aug 1992 18:04:14 -0700
From:	Steve Charlton <steve@silver.cs.umanitoba.ca>
To:	moo-cows@parc.xerox.com
Subject: Re: Server errors...

I ran into the same problem about a year ago, and eventually fixed
it (although I never did figgure out what was wrong).
I can email a corrected bsd_network.c if anyone is interested.

	Steve

From steer.sdsu.edu!waffle Thu Aug  6 22:36:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "22:26:22" "-0700" "4321 tnuoccA cireneG" "waffle@steer.sdsu.edu " nil "37" "Vt100 support" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 6 Aug 1992 22:36:23 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12028>; Thu, 6 Aug 1992 22:35:15 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12030>; Thu, 6 Aug 1992 22:33:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58403>; Thu, 6 Aug 1992 22:25:21 -0700
Received: from steer.sdsu.edu ([130.191.1.11]) by alpha.xerox.com with SMTP id <11952>; Thu, 6 Aug 1992 22:24:53 PDT
Received: by steer.sdsu.edu; id AA02588
	sendmail 5.65c/SDSU-GW-1.5
	Thu, 6 Aug 1992 22:26:23 -0700 for moo-cows@parc.xerox.com
X-Mailer: ELM [version 2.3 PL3]
X-NS-Transport-ID: 08002008D0FD002140C1
Message-ID: <199208070526.AA02588@steer.sdsu.edu>
Date:	Thu, 6 Aug 1992 22:26:22 -0700
From:	waffle@steer.sdsu.edu (4321 tnuoccA cireneG)
To:	moo-cows@parc.xerox.com
Subject: Vt100 support

yduJ said:
>I don't know if it's been advertised here yet, but waffle on LambdaMOO
>has built some MOO code support for color coding messages for those
>without good client support.  I think you have to be using some PC
>running DOS or something, and you change your character map locally so
>that tilde (gets turned into escape (which MOO won't print), and you
>get pages in red, whispers in yellow, etc.  I don't know the details
>(not being a PC user and preferring emacs-based interfaces) but I think
>waffle has written doc.  Is waffle on this list?  Care to advertise?

Someone not yduJ said:
>Common interface: writing to the common interface may not be as
>silly as it seems. Practically every terminal maker, computer system
>maker provides vt100/220 emulation. In the 80s many of us wasted
>our life away playing rogue. Didn't you just hate 'R' at about
>level 8? There are a lot of things that could be played with
>just using the escape sequences.

The color object (#9922 on LambdaMOO, feel free to port elsewhere) hooks on
to the player's :tell verb, and intercepts incoming messages, checking
callers(). If any of the callers matches an object:verb, object, or 
:verb string set by the user, an appropriate ANSI/VT100 color code is sent.
Thus, as yduJ said, pages may be in red, login watcher messages in green,
everything else in white. As noted, MOO wont send ASCII 27, to instead
I have it send a tilde - the user needs an input translation table to
change the tilde to an ESC (ASCII 27). Voila, anyone with ANSI and a
translation table (IBM and MAC people - as long as you have a good term
program) can get color.

Although I dont know the codes, you can do other things with ANSI/VT100,
including setting terminal characteristics, programming function keys,
and playing music.

-waffle
Kevin Savetz
waffle@steer.sdsu.edy


From steamer.clam.com!jeff Fri Aug  7 06:28:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "06:15:01" "-0700" "Jeff d'Arcy" "jeff@steamer.clam.com " nil "18" "Re: Server errors..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 7 Aug 1992 06:28:51 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11701>; Fri, 7 Aug 1992 06:27:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11692>; Fri, 7 Aug 1992 06:25:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 7 Aug 1992 06:17:31 -0700
Received: from steamer.clam.com ([192.124.136.113]) by alpha.xerox.com with SMTP id <11692>; Fri, 7 Aug 1992 06:17:05 PDT
Received: by steamer.clam.com (AIX 3.2/UCB 5.64/4.03)
          id AA51362; Fri, 7 Aug 1992 09:15:01 -0400
X-NS-Transport-ID: 08002008D0FD0021446E
Message-ID: <9208071315.AA51362@steamer.clam.com>
Date:	Fri, 7 Aug 1992 06:15:01 -0700
From:	jeff@steamer.clam.com (Jeff d'Arcy)
To:	moo-cows@parc.xerox.com, steve@silver.cs.umanitoba.ca
Subject: Re: Server errors...


>Message-Id: <9208070104.AA04200@carbon.cs.umanitoba.ca>
>Subject: Re: Server errors...
>To: moo-cows@parc.xerox.com
>Date: 	Thu, 6 Aug 1992 18:04:14 PDT
>
>I ran into the same problem about a year ago, and eventually fixed
>it (although I never did figgure out what was wrong).
>I can email a corrected bsd_network.c if anyone is interested.
>
>	Steve

While we're at it, I have a version of bsd_network.c that had to be modified to
work on my Stardent Vistra (UNIX V.4) workstation.  Should we set up a central
repository for these, or should we turn the distributed version of the file
into a preprocessor's worst nightmare?

	jeff

From parc.xerox.com!pavel Fri Aug  7 10:28:23 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "10:21:36" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "51" "Re: Just some general questions and a request." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 7 Aug 1992 10:28:13 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11752>; Fri, 7 Aug 1992 10:27:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11733>; Fri, 7 Aug 1992 10:24:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Fri, 7 Aug 1992 10:22:02 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11710>; Fri, 7 Aug 1992 10:21:49 PDT
Received: by lambda.parc.xerox.com id <58397>; Fri, 7 Aug 1992 10:21:45 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0021488B
In-Reply-to: <712608489.15850.0@freehold.andrew.cmu.edu>
Message-ID: <92Aug7.102145pdt.58397@lambda.parc.xerox.com>
References: <712608489.15850.0@freehold.andrew.cmu.edu>
Date:	Fri, 7 Aug 1992 10:21:36 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	jtraub+@cmu.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: Just some general questions and a request.

> Date:	Fri, 31 Jul 1992 11:48:09 -0700
> From:	Moonchilde <jtraub+@cmu.edu>

I could *swear* that I replied to this message when it came in, but I can't
find any evidence of that in the MOO-Cows archive, so...  Sorry if this is,
indeed, some kind of repeat.

> Haakon: do you have any plans to add the GodNET regexp and listassoc
> code to the standard MOO release? it's really a pain to keep patching them
> in. :)

The next release, in a week or so, will very likely contain new built-in
functions covering the functionality of the GodNet regexp functions.  Almost
certainly, however, those functions will not have the same interface/names as
on GodNet; I believe that better names (and perhaps somewhat more flexible
functionality) are possible.

As for the listassoc() and listiassoc() functions, I do not have any plans at
this time to include those in the release.  Instead, I believe that the second
release from now (scheduled for the end of August and including reference
counting instead of ubiquitous value copying) will perform so much better,
especially on applications that manipulate large list structures, that it will
no longer be useful to move those functions into C.

>   I would like a function similar to notify() that does not append the output
> text with a newline/line feed.  This would make interactive prompting look
> a little cleaner, and shouldn't be all that hard to do.

There are some tricky questions concerning the design of a good MUD client that
copes both with asynchronous output from the server and with maintaining a
readable prompt for the user.  For example, how do you know that an incomplete
line of output is a prompt and not simply a packet boundary in the TCP stream?
[Assume that you fix this by having prompt lines end in a special character for
easy recognition, say ASCII NUL.]  Now, suppose you, the client, have received
a prompt that the user hasn't responded to yet, so you're keeping the prompt
intact while letting all the later, asynchronously-generated output scroll by.
What if another prompt comes in before the user has responded to this one?
Should you just queue it up?  Maybe throwm away the old one and use the new one
instead?

And then there are the issues about user confusion, when some nasty task prints
a prompt but then doesn't try to read any input; the poor user thinks he's
answering the prompt when in fact he's typing a MOO command.  Just think of the
possibilities for fun!  :-)  This sort of thing could be handled by proper core
database design, but it's certainly an issue that must be addressed.

Anyhow, it wouldn't be very hard at all to implement such an addition; I just
haven't been motivated to put it very high on my long list of things to do,
pending some resolution of the issues I sketched out above.

	Pavel

From parc.xerox.com!pavel Fri Aug  7 11:18:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "11:10:18" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "60" "MOO for many `networks'" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 7 Aug 1992 11:18:47 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11742>; Fri, 7 Aug 1992 11:18:16 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11736>; Fri, 7 Aug 1992 11:13:36 PDT
Received: by lambda.parc.xerox.com id <58372>; Fri, 7 Aug 1992 11:10:19 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002149A8
Message-ID: <92Aug7.111019pdt.58372@lambda.parc.xerox.com>
References: <199208040226.AA10001@morwyn.UUCP>
Date:	Fri, 7 Aug 1992 11:10:18 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: MOO for many `networks'

> Date:	Mon, 3 Aug 1992 19:26:41 -0700
> From:	Forrie Aldrich <forrie@morwyn.uucp>
> 
> There was some brief speculation/talk earlier about hacking LambdaMOO to
> compile and run on a non-networking machine.  The subject was quickly
> dropped; however, I'm curious if anything resulted from this or if anyone
> has accomplished this task.

Well, I've finally gotten sufficiently tired of saying `no' to this question
(which I've heard many times from many people) and also gotten sufficiently
motivated to acquire a very good book covering all of the standard UNIX
networking and interprocess communication facilities (both BSD and SysV).  I
plan to include in an upcoming release (maybe the one in a week or so, but more
likely the one after that, at the end of August) support for several different
kinds of networking in the official MOO release.

Here are the networking kinds I am prepared to support:

1) For BSD-style systems that *have* access to a real TCP network, code
   like that currently in the server, using AF_INET sockets.

2) For BSD-style systems that *do not have* network access, code using
   AF_UNIX sockets.

3) For SysV-style systems that *have* access to a real TCP network, code using
   the TLI interface and assuming the existence of /dev/tcp.

4) For SysV-style systems that *do not have* network access, code using either
   FIFOs or message queues.

5) For most systems, including some non-UNIX platforms, a single-user set-up in
   which the user is `connected' on the standard input and output of the server
   program itself.

The code will be organized such that options 1-4 share a new, generic version
of bsd_network.c that makes calls on a small number of routines for which each
option will provide a different implementation.  Option 5 will replace
bsd_network.c entirely.

I have included among the options only those that I can test out myself locally
and that appear to have people who need them.  If you need some option that's
not listed above AND you're willing and able to provide me with detailed
documentation for that option AND you're willing to act as a *responsive*
testing site, please feel free to write me (not the MOO-Cows list).

For options 2 and 4, users will not be able to use `telnet' or any of the other
standard MUD client programs, since the servers will not be listening for TCP
connections.  I intend also to make available a version of tinytalk that can be
compiled in a compatible way to make connecting easy.

Finally, if you're a knowledgeable SysV user, I have some extra questions for
you:

-- Does every SysV box have both FIFOs and message queues?
-- Are there SysV boxes that provide both TLI and /dev/tcp but not BSD-style
   sockets?
-- Is there more than one set of conventions for using /dev/tcp?  I only know
   of the one described in the book `UNIX Network Programming'.

	Pavel/Haakon

From oxy.edu!bdrake Fri Aug  7 11:23:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "11:16:59" "-0700" "Barry T. Drake" "bdrake@oxy.edu " nil "15" "New server versions" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 7 Aug 1992 11:23:47 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11705>; Fri, 7 Aug 1992 11:23:22 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11712>; Fri, 7 Aug 1992 11:20:17 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 7 Aug 1992 11:18:36 -0700
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <11772>; Fri, 7 Aug 1992 11:16:23 PDT
Received: by gate.oxy.edu (4.0/SMI-4.0)
	id AA15657; Fri, 7 Aug 92 11:16:59 PDT
X-NS-Transport-ID: 08002008D0FD002149E1
Message-ID: <9208071816.AA15657@gate.oxy.edu>
Date:	Fri, 7 Aug 1992 11:16:59 -0700
From:	bdrake@oxy.edu (Barry T. Drake)
To:	moo-cows@parc.xerox.com
Subject: New server versions


Well, if there are to be two more releases before the end of august,
how about sneaking in some of my ideas?  Besides '++' and '+=' et. al.,
A really useful and easy primitive would be the following:

log(string)


This would be a wiz only primitive which would write to the log file the date,
time etc, followed by the string.  This way, wizzes can log things without fi
(ooops)  The wizzes could log important things to the moo's machine, instead
of inside the db.  This seems easy to me, so I may add it myself, if it's
not in a future version.

bdrake

From parc.xerox.com!pavel Fri Aug  7 11:28:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "11:22:28" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "21" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29582>; Fri, 7 Aug 1992 11:28:03 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11757>; Fri, 7 Aug 1992 11:27:24 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11735>; Fri, 7 Aug 1992 11:25:18 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 7 Aug 1992 11:23:11 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11705>; Fri, 7 Aug 1992 11:22:46 PDT
Received: by lambda.parc.xerox.com id <58372>; Fri, 7 Aug 1992 11:22:40 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00214A05
In-Reply-to: <9208040030.AA11339@gate.oxy.edu>
Message-ID: <92Aug7.112240pdt.58372@lambda.parc.xerox.com>
References: <9208040030.AA11339@gate.oxy.edu>
Date:	Fri, 7 Aug 1992 11:22:28 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	bdrake@oxy.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO

> Date:	Mon, 3 Aug 1992 17:30:12 -0700
> From:	bdrake@oxy.edu (Barry T. Drake)
> 
> Well, I'll probably get chewed for this one, but how about this sticky idea:
> 
> Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
> I think they are more readable, but perhaps that is only me.  Just an
> idea. :)

I think, personally, that these bits of syntax would tend to make MOO programs
*harder* to understand, especially for novices, without adding very much in the
way of convenience.  My plans for the syntax, actually, are to try to make it
*less* like C and more like, say, Modula.  For example, I'd like to get rid of
the required parentheses in IF statements and put in instead a required THEN
keyword.  I'd like to replace the cryptic !, &&, and || operators with the
English keywords NOT, AND, and OR.  I'd *love* to get rid of the confusing and
error-prone = and == operators, possibly replacing them by := and the keyword
IS.  I'd use := and =, as in Modula, but I fear that keeping = as a operator
while changing its meaning would be too error-prone for long-time MOOers.

	Pavel/Haakon

From stony-brook.scrc.symbolics.com!yduJ Fri Aug  7 11:53:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "11:54:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "23" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 7 Aug 1992 11:53:20 -0700
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11633>; Fri, 7 Aug 1992 11:52:45 PDT
Received: from TRISMEGISTUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1121355; 7 Aug 1992 14:53:26-0400
In-Reply-To: <92Aug7.112240pdt.58372@lambda.parc.xerox.com>
Message-ID: <19920807185400.7.YDUJ@TRISMEGISTUS.SCRC.Symbolics.COM>
Date:	Fri, 7 Aug 1992 11:54:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	Pavel@parc.xerox.com, bdrake@oxy.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO

    Date: Fri, 7 Aug 1992 14:22 EDT
    From:	Pavel Curtis <Pavel@parc.xerox.com>

    > Date:	Mon, 3 Aug 1992 17:30:12 -0700
    > From:	bdrake@oxy.edu (Barry T. Drake)
    > 
    > Well, I'll probably get chewed for this one, but how about this sticky idea:
    > 
    > Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
    > I think they are more readable, but perhaps that is only me.  Just an
    > idea. :)

    I think, personally, that these bits of syntax would tend to make MOO programs
    *harder* to understand, especially for novices, without adding very much in the
    way of convenience.

Mass quantities of seconding Pavel's assertion that ++ etc. are harder
to understand.  Personally, not being much of a C programmer, I hate it
when people use these constructs; the semantics aren't intuitively
obvious and I have to think too much to read their code, unlike more
verbose code which spells out the order in which things happen.

					yduJ

From ee.ualberta.ca!daum Fri Aug  7 12:03:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "11:53:10" "-0700" "Ryan Daum" "daum@ee.ualberta.ca" nil "31" "sqrt() function in the MOO server" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 7 Aug 1992 12:02:51 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11752>; Fri, 7 Aug 1992 12:01:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11755>; Fri, 7 Aug 1992 11:59:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58397>; Fri, 7 Aug 1992 11:57:54 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11720>; Fri, 7 Aug 1992 11:54:25 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11750>; Fri, 7 Aug 1992 11:53:35 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA05480; Fri, 7 Aug 92 12:53:12 -0600
Full-Name: Ryan Daum
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD00214A89
Message-ID: <92Aug7.115335pdt.11750@alpha.xerox.com>
Date:	Fri, 7 Aug 1992 11:53:10 -0700
From:	Ryan Daum <daum@ee.ualberta.ca>
To:	moo-cows.PARC@xerox.com
Subject: sqrt() function in the MOO server

One thing I've added to my local LambdaMOO server (which is the version run by
GodNet) is a sqrt() function.

The reason for adding this was to increase speed when calculating the 3d
distance formulas we are working on here.

I'd like to see htis added as a standard functin.

In addition, considering the monthly updates of LambdaCore that we cannot
"patch" into our existing database, I'd like to suggest the following for
discussion:

	Some standard way of seperating "Core" from "database."

That is, have two seperate files -- one being the core database (i.e.
LambdaCore) and the other being the database file of objects that exist outside
of it.

Core database object #s  would differ slightly, so that they wouldn't interfere
with the number count.  Lets say we "reserve" the first two hundred objects or
so (make it a compile time option) for core database, and from #200 on would be
standard objects.

When a new core databas is created, it would contain a list of the differences
between the object numbers of it and the previous version.  So, all children of
$player on the old database would be recognized and CHparented to $player in
the new database, which would have been "patched" into that #0..#199 area.

Sounds far-fetched, but it really is a pain seeing how much nicer the latest
LambdaCore is *after* having built 50 objects on top of the old one.


From computing-maths.cardiff.ac.uk!Andrew.Wilson Fri Aug  7 15:45:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "7" "August" "1992" "15:18:01" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "70" "Improving the server (and VROOMs too!)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Fri, 7 Aug 1992 15:45:26 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11772>; Fri, 7 Aug 1992 15:44:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11749>; Fri, 7 Aug 1992 15:39:10 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 7 Aug 1992 15:33:22 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11749>; Fri, 7 Aug 1992 15:33:09 PDT
Via: uk.ac.cardiff.computing-maths; Fri, 7 Aug 1992 23:18:16 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <06318-0@sentinel.cm.cf.ac.uk>; Fri, 7 Aug 1992 23:18:06 +0100
X-NS-Transport-ID: 08002008D0FD00214E97
Message-ID: <9208072218.AA21070@turquoise.cm.cf.ac.uk>
Date:	Fri, 7 Aug 1992 15:18:01 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com
Subject: Improving the server (and VROOMs too!)



Hi,
	top of my "If only MOO could do this!" list HAS to be
a resume() command.

You normally suspend a task in MOO by using a suspend(Seconds) call
which suspends the task for so many seconds and then gets going again.
What I'd like to be able to do is something like:

	"myverb"
	MyTask = task_id();
	fork (0)
		"do something involved and time consuming"
		Results = <something or other>;
		resume(MyTask);
	endfork;
	ReturnValue = suspend(10);
	if (ReturnValue = E_TIMEOUT)
		player:tell("We're having problems, sorry.");
	else
		player:tell("Ok, the results are: ", Results);
	endif;

This means that suspend() would return E_TIMEOUT if its allotted 10 seconds
were up and E_RESUMED (say) if the task had been resumed by the action
of some other agent in the MOO.

Note that E_TIMEOUT does not mean that the command failed, just that the
calling verb ran out of time.  It's up to the caller of suspend() to
interpret the return value wisely.

The principal advantage of resume() is that you don't have to keep polling
the value of 'Results' every second or so like you do at the moment:

	"myotherverb"
	Results = $nothing;
	fork (0)
		"do something involved and time consuming"
		Results = <something or other>;
	endfork;

	TimeOut = 0;
	while (Results == $nothing && TimeOut < 10)
		sleep(1);
		TimeOut = TimeOut + 1;
	endwhile;
	if (Results == $nothing)
		player:tell("We're having problems, sorry.");
	else
		player:tell("Ok, the results are: ", Results);
	endif;

An additional advantage is that the semantics of suspend() are unchanged
as far as existing code is concerned.  A call like suspend(10) will STLL
resume its calling task after 10 seconds.

This feature is really too sexy to pass up.  Please, please, please
put it in the next version of the MOO server.

Luv, Andrew Wilson.

ps.  The VROOM concept works.  I have it running on 3 machines with a
Vtopology of 4 VROOMs.  Occupants of a VROOM can use the 'say', 'emote'
and 'look' commands as you'd expect for a normal $room.  I'll have more to
say about an evaluation package I'm building for publication next week,
if anyone's interested that is.  He, he, he.

I feel GOOD!


From doc.imperial.ac.uk!mjb Sat Aug  8 14:28:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "8" "August" "1992" "14:23:25" "-0700" "mjb@doc.imperial.ac.uk" "mjb@doc.imperial.ac.uk" nil "67" "More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Sat, 8 Aug 1992 14:28:15 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11844>; Sat, 8 Aug 1992 14:27:43 PDT
Via: uk.ac.imperial.doc; Sat, 8 Aug 1992 22:27:16 +0100
In-reply-to: Pavel Curtis's message of Fri, 7 Aug 1992 11:22:28 PDT <92Aug7.112240pdt.58372@lambda.parc.xerox.com>
Message-ID: <9208082223.aa15057@puffin.doc.ic.ac.uk>
Date:	Sat, 8 Aug 1992 14:23:25 -0700
From:	mjb@doc.imperial.ac.uk
Sender: mjb@doc.imperial.ac.uk
To:	Pavel@parc.xerox.com
CC:	bdrake@oxy.edu, moo-cows@parc.xerox.com
Subject: More C-like MOO

   From: Pavel Curtis <Pavel@parc.xerox.com>
   Original-Sender: Pavel Curtis <pavel@parc.xerox.com>
   Fake-Sender: pavel@parc.xerox.com
   References: <9208040030.AA11339@gate.oxy.edu>
   Date: Fri, 7 Aug 1992 11:22:28 PDT
   Sender: pavel <@alpha.xerox.com:pavel@parc.xerox.com>

   > Date:	Mon, 3 Aug 1992 17:30:12 -0700
   > From:	bdrake@oxy.edu (Barry T. Drake)
   > 
   > Well, I'll probably get chewed for this one, but how about this sticky 
   > idea:
   > 
   > Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
   > I think they are more readable, but perhaps that is only me.  Just an
   > idea. :)

   I think, personally, that these bits of syntax would tend to make MOO
   programs *harder* to understand, especially for novices, without adding
   very much in the way of convenience.

I agree with Haakon here. In C these are just shorthand forms, useful only
for making code more concise. IMHO if you're writing an expression that
needs to have these operators for clarity, you should look into breaking it
up into several expressions.

   My plans for the syntax, actually, are to try to make it *less* like C
   and more like, say, Modula. For example, I'd like to get rid of the
   required parentheses in IF statements and put in instead a required
   THEN keyword.  I'd like to replace the cryptic !, &&, and || operators
   with the English keywords NOT, AND, and OR.

Now this, I disagree with. I'm not a great fan of languages (eg. Modula)
that use a lot of English keywords. I do not believe that Modula code
is very much more readable than C to the total novice, while the long,
awkward, verbose syntax makes writing code more of a chore. IMHO it is
difficult *concepts*, and easily-misused operators, that cause newbie
programmers trouble, not whether things are in pseudo-English.

In other words, I think that such changes would only add verbosity, while
not doing much for clarity (since no language can be properly understood
without reading the documentation anyway).

At least MOO, with its case-blindness, wouldn't force these keywords to
be in all UPPER CASE like modula... (I hope!)

   I'd *love* to get rid of the confusing and error-prone = and == 
   operators, possibly replacing them by := and the keyword IS.

Agreed. This is a cause of much unnecessary lossage, and one of C's major
syntax misfeatures.

   I'd use := and =, as in Modula, but I fear that keeping = as a operator
   while changing its meaning would be too error-prone for long-time MOOers.

True. A worthwhile thing to remember: if you have to make something break,
make it break *cleanly*. 

	   Pavel/Haakon

-Morven

-- 
| Matthew J. Brown  | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk  | Imperial College,  | lectures He wouldn't have created |
| mjb02@cc.ic.ac.uk | 180 Queen's Gate   | double-sided photocopiers.        |
| Morven on Lambda  | LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

From phyvs1.anu.edu.au!dxb105 Sun Aug  9 20:28:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "10:11:41" "-0700" "David Bofinger" "dxb105@phyvs1.anu.edu.au" nil "42" "MOO and C" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Sun, 9 Aug 1992 20:28:38 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11912>; Sun, 9 Aug 1992 20:28:06 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11909>; Sun, 9 Aug 1992 20:24:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Sun, 9 Aug 1992 20:09:32 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11909>; Sun, 9 Aug 1992 20:09:04 PDT
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <11909>; Sun, 9 Aug 1992 20:08:24 PDT
Received: by phys.anu.edu.au (MX V2.3) id 27200; Mon, 10 Aug 1992 13:11:41 EDT
X-NS-Transport-ID: 08002008D0FD00215AF2
Message-ID: <0095EE36.E1EAE4C0.27200@phys.anu.edu.au>
Date:	Mon, 10 Aug 1992 10:11:41 -0700
From:	David Bofinger <dxb105@phyvs1.anu.edu.au>
To:	MOO-Cows.PARC@xerox.com
cc:	dxb105@phyvs1.anu.edu.au
Subject: MOO and C

>> From:	bdrake@oxy.edu (Barry T. Drake)
>>
>> Well, I'll probably get chewed for this one, but how about this sticky idea:
>>
>> Add '++', '+=', '-=', etc.  I know these are C conventions, but why not?
>> I think they are more readable, but perhaps that is only me.  Just an
>> idea. :)

Pavel replied:

>I think, personally, that these bits of syntax would tend to make MOO programs
>*harder* to understand, especially for novices, without adding very much in the
>way of convenience.

Agreed.

>My plans for the syntax, actually, are to try to make it
>*less* like C and more like, say, Modula.  For example, I'd like to get rid of
>the required parentheses in IF statements and put in instead a required THEN
>keyword.  I'd like to replace the cryptic !, &&, and || operators with the
>English keywords NOT, AND, and OR.

Personally I don't find pseudo-english keywords make anything easier to
understand, but then I'm about as much a mathematician as I am a computer
scientist anyway. People who are half computer scientist and half English
majors probably would, if such people exist.

>I'd *love* to get rid of the confusing and
>error-prone = and == operators, possibly replacing them by := and the keyword
>IS.

I'll vote for := and ==, it's hard to imagine people often using the wrong one
of those, whereas = might get confused with either.

I wonder if it would be possible to write a lint for MOO, that identified
odd-looking code. Probably not, but if anyone does I suggest the name "cud".

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
		MOO:	Marion and the manipulators.
------------------------------------------------------------------------------

From morticia.cnns.unt.edu!cluther Mon Aug 10 10:48:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "09:58:26" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "26" "Server Extensibility" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 10:48:20 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11771>; Mon, 10 Aug 1992 10:40:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11619>; Mon, 10 Aug 1992 10:27:21 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Mon, 10 Aug 1992 10:21:27 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11743>; Mon, 10 Aug 1992 10:10:22 PDT
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11921>; Mon, 10 Aug 1992 09:58:40 PDT
Received: by morticia.cnns.unt.edu id AA04407
  (5.65c/IDA-1.4.4 for moo-cows.PARC@xerox.com); Mon, 10 Aug 1992 11:58:26 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD002160E7
Message-ID: <199208101658.AA04407@morticia.cnns.unt.edu>
Date:	Mon, 10 Aug 1992 09:58:26 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows.PARC@xerox.com (Moo Cows)
Subject: Server Extensibility

Idea to put forward:

Linkable libraries of built-in functions for the moo server.

Purpose:

1) To provide moo admins with a way of adding functionality to the moo server
by writing discrete libraries of their own functions without the need to hack
on the server itself.

2) Increased modularity and compatibility of existing moo servers.  Admins
could share their function modules with other admins.  Other admins could 
add the new built-ins to their moo simply by editing a header file (to
indicate the new functions) and the make file (to ensure the library is
linked) and recompiling.

3) Provides Pavel with a method of maintaining an up-to-date and reliable
core server, while providing other moo admins with the ability to tailor 
their moo with C functions.  


Please discuss.

-- 
Clay Luther
cluther@morticia.cnns.unt.edu

From andrew.cmu.edu!jt1o+ Mon Aug 10 11:03:52 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "10:51:23" "-0700" "Moonchilde" "jtraub+@cmu.edu" nil "12" "Re: Server Extensibility" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 11:03:52 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11617>; Mon, 10 Aug 1992 11:03:05 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11607>; Mon, 10 Aug 1992 11:00:47 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Mon, 10 Aug 1992 10:55:08 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11585>; Mon, 10 Aug 1992 10:54:15 PDT
Received: from po2.andrew.cmu.edu ([128.2.249.105]) by alpha.xerox.com with SMTP id <11601>; Mon, 10 Aug 1992 10:52:26 PDT
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA02749> for moo-cows.PARC@xerox.com; Mon, 10 Aug 92 13:52:14 EDT
Received: via switchmail; Mon, 10 Aug 1992 13:52:09 -0400 (EDT)
Received: from freehold.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.IeVemiC00WD5INYk4K>;
          Mon, 10 Aug 1992 13:51:43 -0400 (EDT)
Received: via niftymail; Mon, 10 Aug 1992 13:51:24 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD00216230
In-Reply-to: <199208101658.AA04407@morticia.cnns.unt.edu>
Message-ID: <713469083.6323.0@freehold.andrew.cmu.edu>
References: <199208101658.AA04407@morticia.cnns.unt.edu>
Date:	Mon, 10 Aug 1992 10:51:23 -0700
From:	Moonchilde <jtraub+@cmu.edu>
Sender: jt1o+@andrew.cmu.edu
To:	Moo Cows <moo-cows.PARC@xerox.com>
Subject: Re: Server Extensibility

I personally think this idea is a very good one, and would like to
see it.

I know that some servers out there would find having heavy math functions
inserver to be an extreme boon, and I know that I find the regexp and
listassoc stuff that Clay wrote for GodNET and distributed to be also
very useful.

Setting up a mechanism whereby module libraries of external functions could
be added to the interpreter easily would be highly nice.
--Moonchilde
(jtraub@cmu.edu)

From cs.stanford.edu!crew Mon Aug 10 11:09:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "10:57:29" "-0700" "Roger Crew" "crew@cs.stanford.edu" nil "85" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 11:09:37 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11608>; Mon, 10 Aug 1992 11:08:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11596>; Mon, 10 Aug 1992 11:06:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Mon, 10 Aug 1992 11:01:00 -0700
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11585>; Mon, 10 Aug 1992 10:57:04 PDT
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA06171; Mon, 10 Aug 92 10:57:29 PDT
X-NS-Transport-ID: 08002008D0FD00216272
Message-ID: <9208101757.AA06171@Xenon.Stanford.EDU>
Date:	Mon, 10 Aug 1992 10:57:29 -0700
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO

Note that in some communities, being more C-like is not considered to be a 
virtue.

Keep in mind that ++, +=, -=, etc... are just instances of C pretending to
be an assembly language; the only point behind having these constructs is
to suggest optimizations to the compiler, and this was only back in the bad
old days when compilers couldn't figure these things out for themselves.
Well okay, MOO probably isn't that good at it yet, but we can suppose that
some day it will be.  Suffice it to say that the main bottlenecks in MOO
lie elsewhere: e.g., having some destructive list operations available
would have a much more significant impact speedwise --- not that I'm actually
suggesting this, mind you; there are lots of good reasons for not doing it.

Meanwhile, here's a big YES vote for
1)  using only := for assignment, 
2)  continuing to use == for the relational equals, and
3)  having = be UNDEFINED.  

Note that continuing to support the old usage of = for assignment would
totally defeat the purpose of making such a change, namely that of guarding
against someone inadvertantly using = for == (as opposed to advertantly
like I do).  Likewise, using = relationally would just create the reverse
problem, one that is, I might add, even more mysterious to diagnose...

Re: pseudo-english keywords:  I hate them.  For one thing, they tend to
block out usable identifiers.  As for newbies, I figure the sooner they
realize they're dealing with something that doesn't actually understand
English, the better.

Actually, I would say the real problem with understanding relational
expressions is not the use of &&, ||, and ! but rather the fact that the
unparser insists on cramming the entire expression onto a single line,
which usually serves to obscure whatever structure it might have.  Now
there *is* something to be said for having all verbcode in a uniform
format.  In particular:

  1) individual styles have less impact on the appearance of code
     thus making other players' code easier to read.  Story:  at one point, 
     someone with a question actually moo-mailed me a rather long piece of code
     rather than simply pointing me to the object where it lived.  Suffice it 
     to say I am now *really* *glad* that the unparser enforces a particular 
     style.

  2) @grep remains possible.  I hate to say it, but this is actually
     important, mainly from a diagnostic point of view (i.e., does anyone 
     really use $foo:bar()??  Let's find out!) but also from a security stand-
     point as well (find me all wizard-owned verbs that call set_verb_code()).

Some time back I actually did try to tackle this problem:  #5803:@prettyprint
(on LambdaMOO) is the result and there are three notable problems with it
  (a) it's horribly slow.
  (b) ...I mean *really* *horribly* *slow*.
  (c) it does idiosyncratic things -- i.e., things that *I* like, but which 
      would draw numerous complaints if this were to be decreed the standard 
      format.

Unfortunately, any attempt to produce a more readable format for long
expressions is doomed to eventually contend with (c) questions of taste that 
might best be left to individual users.  This suggests that, in fact, the 
server is not really the right place to address this.

Note that while uniform formats are good, there's nothing that says the
uniform format has to be a TEXT format (i.e., list of strings) and in fact
I would much prefer it if verb_code()/set_verb_code() dealt with
*parsetrees* rather than lists of strings.  Once we get reference counting
this would even be fast (most of the time in #5803:@prettyprint is taken up
with parsing, and most of the server action is taken up in unnecessary
recopying of the list structures that parsing produces).  

Once verb_code/set_verb_code/@list/@program are dealing with parsetrees,
syntactic styles can, at least in small matters, be customized to suit the
player.  E.g., if you prefer to see AND rather than &&, your @list verb
could be made to do just that, not to mention that it would work the same
way no matter whose code you're looking at, thus keeping the main benefits
of uniformity.  This would also help on @grep since you wouldn't get the
false hits that the purely textbased search available now gives you.

	Roger

ps.  As long as we're on the subject of messing with the language, 
whatever happened to EXIT (a.k.a BREAK) and NEXT (a.k.a. LOOP or CONTINUE)?
I'm getting tired of creating bogus auxiliary verbs just so I can RETURN out
of the middle of them :-)



From suna0.cs.uiuc.edu!scott Mon Aug 10 12:44:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "12:36:29" "-0700" "Jay Scott" "scott@suna0.cs.uiuc.edu" nil "28" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Mon, 10 Aug 1992 12:44:34 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11635>; Mon, 10 Aug 1992 12:44:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11634>; Mon, 10 Aug 1992 12:41:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Mon, 10 Aug 1992 12:36:27 -0700
Received: from sparc7.cs.uiuc.edu ([128.174.244.117]) by alpha.xerox.com with SMTP id <11625>; Mon, 10 Aug 1992 12:36:00 PDT
Received: by sparc7.cs.uiuc.edu id AA08956
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Mon, 10 Aug 1992 14:36:29 -0500
X-NS-Transport-ID: 08002008D0FD0021647E
Message-ID: <199208101936.AA08956@sparc7.cs.uiuc.edu>
Date:	Mon, 10 Aug 1992 12:36:29 -0700
From:	Jay Scott <scott@suna0.cs.uiuc.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO

Changing the MOOspeak's syntax would be a problem for those, like
me, who keep all their code offline. My local code copies are in a
more readable form than the MOO unparser can give me, they contain
comments and organization that are not stored on the MOO, they're
around even when the MOO is down (like now), they don't have to be
fetched before editing, they stay put through crashes, and life
is more pleasant than it would be otherwise. But if MOO syntax changes,
I'll have to update all these files with no more help than I can
find in /usr/bin.

On the other hand, the syntax is pretty icky.

I *vastly* prefer keywords 'and' 'or' and 'not' over && || and !.
I think it makes a difference in readability.

My favorite assignment operator is <-. The old := is not half as nice.
My favorite equality operator is =, but as people have been saying,
this causes confusion among those with faulty childhood education. :-)
I'd settle for == or 'is'.

Nobody has mentioned the inequality operator. I'd say, if equality is
'is' then inequality should be 'isnt'; otherwise, if NOT is ! then
inequality should be !=; otherwise I personally would prefer /=
as in (shield your eyes) Ada, because it is more visually suggestive.
But it might be simplest to keep it as !=.

	Frand
	scott@cs.uiuc.edu

From dartmouth.edu!Falryx Mon Aug 10 13:17:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "06:58:38" "-0700" "Falryx@dartmouth.edu" "Falryx@dartmouth.edu" nil "48" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 13:17:36 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11650>; Mon, 10 Aug 1992 13:16:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11631>; Mon, 10 Aug 1992 13:14:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Mon, 10 Aug 1992 12:58:12 -0700
Received: from coos.dartmouth.edu ([129.170.16.50]) by alpha.xerox.com with SMTP id <11638>; Mon, 10 Aug 1992 12:57:54 PDT
Received: by coos.dartmouth.edu (5.57/Ultrix3.0-C)
	id AA04530; Mon, 10 Aug 92 15:57:25 -0400
X-NS-Transport-ID: 08002008D0FD002164F5
Message-ID: <9208101957.AA04530@coos.dartmouth.edu>
Date:	Mon, 10 Aug 1992 06:58:38 -0700
From:	Falryx@dartmouth.edu
To:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO


>On the other hand, the syntax is pretty icky.

I'm coming from the other direction than many of you - so I'll throw in my
two cents.  I don't know C.  Yes. God forbid I should try and learn MOO w/o
the slightest bit of C knowledge, but there you have it.  I actually know
enough C to compute the amount of mileage your care gave you and nothing
more.

I LIKE the syntax. It serves to help me understand C a little better. It's
a half-step towards 'real' programming languages (or at least, that's how
it feels to this neophyte) and if I can get comfortable with the syntax on
MOO, that makes moving up to C that much easier on me.  MOO is *gasp*
educational for me.


>I *vastly* prefer keywords 'and' 'or' and 'not' over && || and !.
>I think it makes a difference in readability.

Ick. I've gotten used to && || and !, and think they do well. (see above
for extra input which I won't repeat here).

>My favorite assignment operator is <-. The old := is not half as nice.
>My favorite equality operator is =, but as people have been saying,
>this causes confusion among those with faulty childhood education. :-)
>I'd settle for == or 'is'.

I agree however with the general trend on this point. = and == are a bit
confusing. := and == would seem to correct this problem, and the := is like
pascal, so it's not out of the blue - and would be recognized by more
people. 

>Nobody has mentioned the inequality operator. I'd say, if equality is
>'is' then inequality should be 'isnt'; otherwise, if NOT is ! then
>inequality should be !=; otherwise I personally would prefer /=
>as in (shield your eyes) Ada, because it is more visually suggestive.
>But it might be simplest to keep it as !=.

Hey! Good idea! Who in the world came up with <> anyway?
Falryx (or some derivative thereof @ wherever)

---------------------------------------------------------------------------
"I don't know about anyone else,  | "Childhood is short, and maturity lasts
but >I< came from my room, I'm a  | forever." - Calvin and Hobbes.
kid with big plans, and I'm going | 
outside!!!" - Calvin & Hobbes     | "The world is a complicated place..."
---------------------------------------------------------------------------


From andrew.cmu.edu!jt1o+ Mon Aug 10 13:35:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "13:22:32" "-0700" "Moonchilde" "jtraub+@cmu.edu" nil "22" "Re: More C-like MOO" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 13:35:37 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11658>; Mon, 10 Aug 1992 13:34:28 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11639>; Mon, 10 Aug 1992 13:32:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58379>; Mon, 10 Aug 1992 13:24:58 -0700
Received: from andrew.cmu.edu ([128.2.11.131]) by alpha.xerox.com with SMTP id <11639>; Mon, 10 Aug 1992 13:24:35 PDT
Received: by andrew.cmu.edu (5.54/3.15) id <AA17078> for moo-cows@parc.xerox.com; Mon, 10 Aug 92 16:24:28 EDT
Received: via switchmail; Mon, 10 Aug 1992 16:24:27 -0400 (EDT)
Received: from freehold.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.ceVh0DK00WD5AUQU5I>;
          Mon, 10 Aug 1992 16:22:39 -0400 (EDT)
Received: via niftymail; Mon, 10 Aug 1992 16:22:33 -0400 (EDT)
X-NS-Transport-ID: 08002008D0FD00216554
In-Reply-to: <9208101957.AA04530@coos.dartmouth.edu>
Message-ID: <713478152.7082.0@freehold.andrew.cmu.edu>
References: <9208101957.AA04530@coos.dartmouth.edu>
Date:	Mon, 10 Aug 1992 13:22:32 -0700
From:	Moonchilde <jtraub+@cmu.edu>
Sender: jt1o+@andrew.cmu.edu
To:	moo-cows@parc.xerox.com
Subject: Re: More C-like MOO

Well, I know for a fact, that I would absolutely detest removing the
&&, ||, and ! operators in favor of English keywords.

A few reason for this are:
a) I don't think that anglicized programming languages are any more intuitive
   or easily learnable
b) it restricts the possible variable names even further.

I have programmed in quite a few languages, and found the languages
like C with symbolic tokens for And, Or, etc to be more intuitive to me.

I don't believe everyone would find them more intuitive, but I seriously
doubt that it is that hard for a person to learn a very simple programming
language.

My opinion would be that more time should be spent providing easier access
to things that people want to do (like break out of loops) rather than
fixing something that isn't broken.

--Moonchilde
--Moonchilde
(jtraub@cmu.edu)

From morticia.cnns.unt.edu!cluther Mon Aug 10 13:54:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "13:38:47" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "40" "Comments on Moo Syntax" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 13:54:38 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11678>; Mon, 10 Aug 1992 13:53:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11667>; Mon, 10 Aug 1992 13:51:27 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58380>; Mon, 10 Aug 1992 13:40:10 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11650>; Mon, 10 Aug 1992 13:39:36 PDT
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11657>; Mon, 10 Aug 1992 13:38:49 PDT
Received: by morticia.cnns.unt.edu id AA06167
  (5.65c/IDA-1.4.4 for moo-cows.PARC@xerox.com); Mon, 10 Aug 1992 15:38:48 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD00216581
Message-ID: <199208102038.AA06167@morticia.cnns.unt.edu>
Date:	Mon, 10 Aug 1992 13:38:47 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows.PARC@xerox.com (Moo Cows)
Subject: Comments on Moo Syntax

Musing:

If moo would only support comments stored in the code.  The original reason
for not having them seems faulty given that in the same breath the author goes
on to say "use strings instead."

It would just be great to use some comment delimiter, like //.  I mean,
we use comment strings *anyway* and comments do add a great deal of
readability to the code.

As far as for converting C-like symbols to Pascal/Modula/Hypertalk/Ada-like
ands, ors, and nots....welllllll, I find I can read either just as well.  Once
the syntax is learned, I don't have any trouble reading the code whether it
says (x && y) or (x and y).

Since moo doesn't support bitwise & and | ops, I see no compelling syntactical
reason to change moo's logical ops.

HOWEVER, = and == can lead to devastating consequences very easily in moo.  I
would break from C tradition here and go with the Pascally := for becomes.  It
actually adds clarity: 

  := becomes
  == equals
  != not equals

  = syntax error

I would also disagree with syntasugar-phobes like Judy who claim +=, -=, ++,
and -- make the code "unclear."  On the contrary, I find these operators to
be very concise.  Of course, I had to *learn* what they meant, but that took all
of a minute.  I wish moo had them.

Finally, a break statement for loops would be very nice indeed.  Hey,
while we're at it, let's go two-whole steps backward and add labels and gotos
(just *kidding*).

-- 
Clay Luther
cluther@morticia.cnns.unt.edu

From cyber.widener.edu!Joshua.R.Poulson Mon Aug 10 14:05:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "14:40:22" "-0700" "Joshua.R.Poulson@cyber.widener.edu" "Joshua.R.Poulson@cyber.widener.edu" nil "16" "Towards a more C-like atmosphere." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 14:05:09 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11658>; Mon, 10 Aug 1992 14:03:53 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11679>; Mon, 10 Aug 1992 14:02:19 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58381>; Mon, 10 Aug 1992 13:51:31 -0700
Received: from cyber.Widener.EDU ([147.31.1.13]) by alpha.xerox.com with SMTP id <11654>; Mon, 10 Aug 1992 13:47:48 PDT
Received: from US*ATTMAIL*WIDE by widener-mg.Widener.EDU via QTFS with X.400;
 Mon, 10 Aug 92 16:40:23 -0500
X400-Trace: US*ATTMAIL*WIDE; arrival Mon, 10 Aug 92 16:40:22 -0500 action
 Relayed
P1-Message-ID: US*ATTMAIL*WIDE; 920810163543406-MTABWIDENER
UA-Content-ID: 920810163543406-
X-NS-Transport-ID: 08002008D0FD00216626
Message-ID: <920810163543406-MTABWIDENER*Joshua.R.Poulson@cyber.Widener.EDU>
Date:	Mon, 10 Aug 1992 14:40:22 -0700
From:	Joshua.R.Poulson@cyber.widener.edu
To:	moo-cows@parc.xerox.com
Subject: Towards a more C-like atmosphere.

Well... if we want to get more C-like, how about handling parenting like this:

#include #65.generic_person
#include #67.generic_magic_user
#include #69.generic_combat
etc.

I, for one, would prefer to avoid the cascade of parents we need to accompish
things that inherit properties from a variety of sources.

To add my note to the other discussion, I would like the more standard C
and, or, and not operators as well as ++, += and the like. I'm quite used
to them and with a little practice, few people have trouble seeing them.
Frankly, any obfuscated C can be translated with a nice listing program.

Later! --JRP [Shirgall@Lambda and various other places]

From sting.berkeley.edu!dougo Mon Aug 10 17:37:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "6" "August" "1992" "23:39:30" "-0700" "Doug Orleans" "dougo@sting.berkeley.edu" nil "21" "Re: MOO network clients" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 17:37:12 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11658>; Mon, 10 Aug 1992 17:36:46 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11692>; Mon, 10 Aug 1992 17:31:33 PDT
Received: by lambda.parc.xerox.com via suspension id <58383>; Mon, 10 Aug 1992 17:26:45 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58382>; Mon, 10 Aug 1992 15:50:01 -0700
Received: from sting.Berkeley.EDU ([128.32.138.4]) by alpha.xerox.com with SMTP id <11684>; Mon, 10 Aug 1992 15:49:34 PDT
Received: by sting.Berkeley.EDU (5.65/XCF-1.34)
	id AA14399; Thu, 6 Aug 92 23:39:33 -0700
X-Face: (4D-osoq?}7M3\EgvbWKo<JkN/8h)A`1b^S1[8/OtYE1A61B!AOmH#YD+{HKhr7}
	@8gMv~.tsxTzT"g.oP0dTl!q
X-NS-Transport-ID: 08002008D0FD002169F0
In-Reply-to: "Your message of \"Thu, 06 Aug 92 09:13:39 PDT.\"
             <9208061613.AA05241@lucifer.Interlan.COM>s"
Message-ID: <9208070639.AA14399@sting.Berkeley.EDU>
Date:	Thu, 6 Aug 1992 23:39:30 -0700
From:	Doug Orleans <dougo@sting.berkeley.edu>
To:	billl@lucifer.interlan.com (sweet william)
cc:	moo-cows@parc.xerox.com, fmpl@sting.berkeley.edu
Subject: Re: MOO network clients

 > I was interested to read Glen Daniels' suggestion about a MOO 
 > IRC client, and was wondering what the MOO community at large
 > thought about extending MOOs to talk to outside network sources:
 > is this a sufficient and viable interface to all the services
 > the internet can provide?  Will people be interested in going to
 > the trouble of learning MOO to use its interface to speak out
 > to the net?

I just wanted to point out that FMPL was designed for almost exactly this
purpose-- to provide a high-level interface for writing networking programs.
While it may not be any easier to use than MOO, it is certainly more
versatile in terms of what you can do with network connections, both
incoming and outgoing.  Instead of just being a mud with an
open_network_connection primitive hacked in, it is a full-featured network
programming language.

FMPL is available via anonymous ftp from xcf.berkeley.edu:src/local/fmpl.
There is also a mailing list for discussion: send mail to
fmpl-request@xcf.berkeley.edu to subscribe.

-- DougO, aka WhiteRabbit

From ecsuc.ctstateu.edu!PLUMMERS Mon Aug 10 19:15:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "19:07:26" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "13" "network hacks..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 19:15:33 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11713>; Mon, 10 Aug 1992 19:13:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11708>; Mon, 10 Aug 1992 19:12:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58382>; Mon, 10 Aug 1992 19:05:44 -0700
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <11696>; Mon, 10 Aug 1992 19:05:18 PDT
X-Vmsmail-To: SMTP%"MOO-Cows@parc.xerox.com"
X-NS-Transport-ID: 08002008D0FD00216B28
Message-ID: <920810220726.202050a9@ECSUC.CTSTATEU.EDU>
Date:	Mon, 10 Aug 1992 19:07:26 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	MOO-Cows@parc.xerox.com
Subject: network hacks...


    God I wish I understood sockets! Well IRC clients and most Unix stuff
has been ported over to VMS...it is about time a MU* did too...those of us
unfortuanates have _yet_ to be able to get a good MU* that works in the
super-Mini realm =(
     I know that VMS supports most Unix sockets, but it seems my school has
a slight problem with all the code...the only file I haven't found has
been inetiodef.h and ioctl.h (but they are on most VMS hacks, so they exist)
I can NOT use MAKE files...but that has been solved in one way or another.
Anyone who is in the least bit interested should take a look at some old
UMBERMUD code, that was ported out to VMS....I would appreciate it greatly.
Or if someone wants to ú&Ï
Ù`Û

From ecsuc.ctstateu.edu!PLUMMERS Mon Aug 10 19:31:06 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "19:17:27" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "21" "network hacks" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 19:31:04 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11696>; Mon, 10 Aug 1992 19:29:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11705>; Mon, 10 Aug 1992 19:27:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58384>; Mon, 10 Aug 1992 19:16:05 -0700
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <11696>; Mon, 10 Aug 1992 19:15:18 PDT
X-Vmsmail-To: SMTP%"MOO-cows@parc.xerox.com"
X-NS-Transport-ID: 08002008D0FD00216B48
Message-ID: <920810221727.202026b4@ECSUC.CTSTATEU.EDU>
Date:	Mon, 10 Aug 1992 19:17:27 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	MOO-cows@parc.xerox.com
Subject: network hacks


     Well now that such a great supject came up I can put in my two cents =)
I use VMS and unfortuantly for me my sys admin isn't interested in Ultrix.
Only 1 MUD has been ported to VMS and that is UmberMud. I would be really
nice to see something for us who are forced to use Super-minis =(
    VMS supports some forms of BSD networking in the latest edition, and I
have seen lots of Unix stuff ported out to VMS.
     My school seems to be missing 2 files inetiodef.h and ioctl.h, and
I have a hard time compiling clients because of it, but alot of the bigger
VMS schools have them. If anyone is interested I can send them a list of
the Multinet files that _we_ have and compare them to Unix. I think my 
school renamed a few files though, but I am just running on rumor, since
I have seen alot of VMS users who also are missing the same files, yet I
meet many who have them...so I am not sure (I think it depended if DEC installed
Muti-net or they did it themselves) 
     So anyone interested in working on this, or with me(??) (I'm clueless
about Unix and networking) I will help am much as I can. Please look at 
UmberMUD or an IRC client (which I can only run the binary of *sniff*)

			Thanx,
			Steve/Saruman

From computing-maths.cardiff.ac.uk!Andrew.Wilson Mon Aug 10 19:39:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "19:26:17" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "17" "Re: network hacks..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 19:39:04 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11718>; Mon, 10 Aug 1992 19:37:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11709>; Mon, 10 Aug 1992 19:35:27 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58385>; Mon, 10 Aug 1992 19:27:40 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11705>; Mon, 10 Aug 1992 19:27:00 PDT
Via: uk.ac.cardiff.computing-maths; Tue, 11 Aug 1992 03:26:54 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <14702-0@sentinel.cm.cf.ac.uk>; Tue, 11 Aug 1992 03:26:26 +0100
X-NS-Transport-ID: 08002008D0FD00216B55
Message-ID: <9208110226.AA07403@pearl.cm.cf.ac.uk>
Date:	Mon, 10 Aug 1992 19:26:17 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-Cows@parc.xerox.com
Subject: Re: network hacks...

So,

PLUMMERS@ecsuc.ctstateu.edu said:

>Anyone who is in the least bit interested should take a look at some old
>UMBERMUD code, that was ported out to VMS....I would appreciate it greatly.
>Or if someone wants to ú&Ï
>Ù`Û

and choked on it apparently, poor lamb.

Andy.	LambdaMOO 9th August 92:
	"Jonny knows about VROOMs and thinks they're misguided."
	"Guest can't understand why people aren't more enthusiastic about"
	"VROOMs, no matter how you implement them...."
	"Guest feels put out."


From ecsuc.ctstateu.edu!PLUMMERS Mon Aug 10 19:51:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "19:43:42" "-0700" "Steve" "PLUMMERS@ecsuc.ctstateu.edu " nil "4" "nope didn't choke" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 19:51:50 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11717>; Mon, 10 Aug 1992 19:51:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11710>; Mon, 10 Aug 1992 19:49:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58386>; Mon, 10 Aug 1992 19:41:44 -0700
Received: from ECSUC.CTSTATEU.EDU ([149.152.30.3]) by alpha.xerox.com with SMTP id <11706>; Mon, 10 Aug 1992 19:41:33 PDT
X-Vmsmail-To: SMTP%"MOO-Cows@parc.xerox.com"
X-NS-Transport-ID: 08002008D0FD00216B70
Message-ID: <920810224342.202026b4@ECSUC.CTSTATEU.EDU>
Date:	Mon, 10 Aug 1992 19:43:42 -0700
From:	PLUMMERS@ecsuc.ctstateu.edu (Steve)
To:	MOO-Cows@parc.xerox.com
Subject: nope didn't choke


    My modem decided to disconnect me....sorry =(

		Saruman

From sting.berkeley.edu!dougo Mon Aug 10 23:49:13 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "10" "August" "1992" "23:40:22" "-0700" "Doug Orleans" "dougo@sting.berkeley.edu" nil "52" "Re: Comments on Moo Syntax" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 10 Aug 1992 23:49:05 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11626>; Mon, 10 Aug 1992 23:48:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11719>; Mon, 10 Aug 1992 23:45:51 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 10 Aug 1992 23:40:58 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11719>; Mon, 10 Aug 1992 23:40:28 PDT
Received: from sting.Berkeley.EDU ([128.32.138.4]) by alpha.xerox.com with SMTP id <11730>; Mon, 10 Aug 1992 23:39:36 PDT
Received: by sting.Berkeley.EDU (5.65/XCF-1.34)
	id AA00803; Mon, 10 Aug 92 23:40:24 -0700
X-Face: (4D-osoq?}7M3\EgvbWKo<JkN/8h)A`1b^S1[8/OtYE1A61B!AOmH#YD+{HKhr7}
	@8gMv~.tsxTzT"g.oP0dTl!q
X-NS-Transport-ID: 08002008D0FD00216D30
In-Reply-to: "Your message of \"Mon, 10 Aug 92 13:38:47 PDT.\"
             <199208102038.AA06167@morticia.cnns.unt.edu>ts wille of be"
Message-ID: <9208110640.AA00803@sting.Berkeley.EDU>
Date:	Mon, 10 Aug 1992 23:40:22 -0700
From:	Doug Orleans <dougo@sting.berkeley.edu>
To:	Clay Luther <cluther@morticia.cnns.unt.edu>
cc:	moo-cows.PARC@xerox.com (Moo Cows)
Subject: Re: Comments on Moo Syntax

 > I would also disagree with syntasugar-phobes like Judy who claim +=, -=, ++,
 > and -- make the code "unclear."  On the contrary, I find these operators to
 > be very concise.  Of course, I had to *learn* what they meant, but that took
 > all of a minute.  I wish moo had them.

Personally, I much prefer


a_very_long_variable_name_or_possibly_a_convoluted_lvalue_expression\
_that_may_take_some_time_to_compute += 36

to

a_very_long_variable_name_or_possibly_a_convoluted_lvalue_expression\
_that_may_take_some_time_to_compute = a_very_long_variable_name_or\
_possibly_a_convoluted_lvalue_expression_that_may_take_some_time_to\
_compute + 36

but maybe I'm exaggerating a bit, especially since I don't think any
MOO expressions result in lvalues.  Plus we all program like
G7 and use variables like k and z.

It's debatable whether

long_name_etc++

is any better than

long_name_etc += 1

especially when, as Roger pointed out, this isn't being compiled
directly into object code where INC and ADD instructions make a big
difference.  But I still prefer ++ and --, just because I'm used to
them.  Same goes for = vs. ==, and && vs. and.

If anyone ever decides to do += et al, a very useful one would be @=:

list_with_long_name_etc @= {foo, bar, baz}

would be equivalent to

list_with_long_name_etc = {@list_with_long_name_etc, @{foo, bar, baz}}

(I think Jonny brought this up first).  But scheme hackers might
prefer

append!(list_with_long_name_etc, {foo, bar, baz})


-- DougO, aka WR, who is less and less interested in MOO the more he
		  plays with FMPL


From parc.xerox.com!pavel Tue Aug 11 17:20:26 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "11" "August" "1992" "17:14:06" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "20" "Re: Server errors..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 11 Aug 1992 17:20:17 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11837>; Tue, 11 Aug 1992 17:19:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11841>; Tue, 11 Aug 1992 17:16:33 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 11 Aug 1992 17:14:50 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11799>; Tue, 11 Aug 1992 17:14:30 PDT
Received: by lambda.parc.xerox.com id <58372>; Tue, 11 Aug 1992 17:14:20 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00217D23
In-Reply-to: <9208062237.AA02172@tusol.cs.trinity.edu>
Message-ID: <92Aug11.171420pdt.58372@lambda.parc.xerox.com>
References: <9208062237.AA02172@tusol.cs.trinity.edu>
Date:	Tue, 11 Aug 1992 17:14:06 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	moo-cows@parc.xerox.com
Subject: Re: Server errors...

> Date:	Thu, 6 Aug 1992 15:37:13 -0700
> From:	rnawara@tusol.cs.trinity.edu (Ray Nawara cs367-fall91)
> To:	moo-cows@parc.xerox.com
> Subject: Server errors...
> 
> After sucessfully compiling, i ran the 1.5.20 server
> , wich i guess was sucessful (im not sure what to look for)
> then i tried to cunnect, which gave me the error "operation not supportd on
> socket" for the command "setting network connection non-blocking"
> this, id guess, means that a socket command is using the wrong syntax...
> (oh im on sun 3 running sunos4.1.1) does anyone know off hand whats wrong?
> 	Ray Nawara (Ash on LambdaMOO)

For anyone else who cares, Ray's problem has to do with a very common error in
the installation of GCC at his site.  I have mailed him my long and detailed
standard explanation of the problem and suggested fixes; I can send copies to
other folks who need it.  If I remember, I'll include the explanation in a
README file in the distribution in the next release.

	Pavel/Haakon

From parc.xerox.com!pavel Tue Aug 11 17:32:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "11" "August" "1992" "17:26:21" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "20" "Re: New server versions" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 11 Aug 1992 17:32:21 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11862>; Tue, 11 Aug 1992 17:29:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11842>; Tue, 11 Aug 1992 17:28:34 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 11 Aug 1992 17:27:08 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11837>; Tue, 11 Aug 1992 17:26:42 PDT
Received: by lambda.parc.xerox.com id <58372>; Tue, 11 Aug 1992 17:26:33 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00217D56
In-Reply-to: <9208071816.AA15657@gate.oxy.edu>
Message-ID: <92Aug11.172633pdt.58372@lambda.parc.xerox.com>
References: <9208071816.AA15657@gate.oxy.edu>
Date:	Tue, 11 Aug 1992 17:26:21 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	bdrake@oxy.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: New server versions

> Date:	Fri, 7 Aug 1992 11:16:59 -0700
> From:	bdrake@oxy.edu (Barry T. Drake)
> 
> Well, if there are to be two more releases before the end of august,
> how about sneaking in some of my ideas?  Besides '++' and '+=' et. al.,
> A really useful and easy primitive would be the following:
> 
> log(string)
> 
> This would be a wiz only primitive which would write to the log file the
> date, time etc, followed by the string.  This way, wizzes can log things
> without fi (ooops) The wizzes could log important things to the moo's
> machine, instead of inside the db.  This seems easy to me, so I may add it
> myself, if it's not in a future version.

The next release of the server will include the functions sqrt(number),
requested by someone else, and server_log(string [,is_an_error]), which is a
slight generalization of Barry's idea above.

	Pavel/Haakon

From parc.xerox.com!pavel Tue Aug 11 17:42:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "11" "August" "1992" "17:36:30" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "48" "Re: Core database updates" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 11 Aug 1992 17:42:36 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11851>; Tue, 11 Aug 1992 17:41:37 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11848>; Tue, 11 Aug 1992 17:39:18 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 11 Aug 1992 17:37:37 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11852>; Tue, 11 Aug 1992 17:37:14 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11848>; Tue, 11 Aug 1992 17:36:44 PDT
Received: by lambda.parc.xerox.com id <58372>; Tue, 11 Aug 1992 17:36:32 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00217D77
In-Reply-to: <92Aug7.115335pdt.11750@alpha.xerox.com>
Message-ID: <92Aug11.173632pdt.58372@lambda.parc.xerox.com>
References: <92Aug7.115335pdt.11750@alpha.xerox.com>
Date:	Tue, 11 Aug 1992 17:36:30 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	daum@ee.ualberta.ca
cc:	moo-cows.PARC@xerox.com
Subject: Re: Core database updates

> Date:	Fri, 7 Aug 1992 11:53:10 -0700
> From:	Ryan Daum <daum@ee.ualberta.ca>

...

> In addition, considering the monthly updates of LambdaCore that we cannot
> "patch" into our existing database, I'd like to suggest the following for
> discussion:
> 
> 	Some standard way of seperating "Core" from "database."
> 
> That is, have two seperate files -- one being the core database (i.e.
> LambdaCore) and the other being the database file of objects that exist
> outside of it.
> 
> Core database object #s would differ slightly, so that they wouldn't
> interfere with the number count.  Lets say we "reserve" the first two hundred
> objects or so (make it a compile time option) for core database, and from
> #200 on would be standard objects.
> 
> When a new core databas is created, it would contain a list of the
> differences between the object numbers of it and the previous version.  So,
> all children of $player on the old database would be recognized and
> CHparented to $player in the new database, which would have been "patched"
> into that #0..#199 area.
> 
> Sounds far-fetched, but it really is a pain seeing how much nicer the latest
> LambdaCore is *after* having built 50 objects on top of the old one.

I can certainly understand your frustration, but I'm not sure that I can see a
good way around the problem.  One difficulty with your idea is that it doesn't
allow for any local changes to the core, since they would be wiped out whenever
the next release of the core occurred.

An idea that I've kicked around for a while now is that it might be feasible to
write an integration tool that took three databases as input: your current
database, the version of the core from which it was built, and the latest
release of the core.  The tool interacts with the user, pointing out decisions
that must be made in merging the core changes into your database.  For things
(broadly construed) that are the same in both cores, it would assume that the
version in your database should be preserved.  For things that are the same in
your database and the old core, but different in the new core, it might presume
to use the new version.  For things different in all three, it would get help
from the user to figure out what to do with them.  There are a *lot* of nasty
details in even such a simple system, though; that's why I've neither written
such a thing or even considered anything more sophisticated.

	Pavel/Haakon

From parc.xerox.com!pavel Tue Aug 11 18:40:52 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "11" "August" "1992" "18:27:32" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "13" "Re: Server Extensibility" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 11 Aug 1992 18:40:42 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11904>; Tue, 11 Aug 1992 18:39:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11865>; Tue, 11 Aug 1992 18:37:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 11 Aug 1992 18:28:23 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11865>; Tue, 11 Aug 1992 18:28:01 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11854>; Tue, 11 Aug 1992 18:27:39 PDT
Received: by lambda.parc.xerox.com id <58372>; Tue, 11 Aug 1992 18:27:35 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00217E32
In-Reply-to: <199208101658.AA04407@morticia.cnns.unt.edu>
Message-ID: <92Aug11.182735pdt.58372@lambda.parc.xerox.com>
References: <199208101658.AA04407@morticia.cnns.unt.edu>
Date:	Tue, 11 Aug 1992 18:27:32 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	cluther@morticia.cnns.unt.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: Server Extensibility

I will do the best I can in the next release to make it easy to add new
built-in functions.  Somewhere, there'll be a list of C functions to be called
when the server starts up, with the intent that they'll register new built-in
MOO functions.  If you add your registration function(s) to the list and add
your .o file(s) to a particular line in the Makefile, your code will be linked
into the server.  See the README file for the details when the release happens.

Beware, though, that the server is going though some pretty pervasive changes
right now and so I can't say much yet about how easy it will be to keep your
code up to date.  Perhaps, after the disk-based-DB maelstrom is over, I'll try
to make it very clear what the `stable' interfaces are within the server.

	Pavel/Haakon

From seagull.tucson.az.us!web Tue Aug 11 19:01:23 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "11" "August" "1992" "17:52:14" "-0700" "Wayne E. Bouchard" "web@seagull.tucson.az.us " nil "23" "server addition" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Tue, 11 Aug 1992 19:01:14 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11885>; Tue, 11 Aug 1992 19:00:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11896>; Tue, 11 Aug 1992 18:58:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 11 Aug 1992 18:55:53 -0700
Received: from Arizona.edu ([128.196.128.234]) by alpha.xerox.com with SMTP id <11909>; Tue, 11 Aug 1992 18:55:33 PDT
Received: from Seagull.Tucson.AZ.US by Arizona.edu (PMDF #12663) id
 <01GNGS07B49SA8J3G7@Arizona.edu>; Tue, 11 Aug 1992 18:55 MST
Received: by Seagull.Tucson.AZ.US (4.1/SMI-4.1) id AA28517; Tue,
 11 Aug 92 18:52:17 MDT
X-Envelope-to: MOO-cows@parc.xerox.com
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00217E8F
Message-ID: <9208120052.AA28517@Seagull.Tucson.AZ.US>
Date:	Tue, 11 Aug 1992 17:52:14 -0700
From:	web@seagull.tucson.az.us (Wayne E. Bouchard)
To:	MOO-cows@parc.xerox.com
Subject: server addition

   Everyone's been talking about what they'ld like in the next release, so I
thought I'ld throw in my two bits. One function that I would find usefull would
be an 'at()' function similar to the unix at which would allow (probably only
wizards) to set up a series of tasks to execute at a specefic time. so you
could say something like:

   at(15:00:00)
    .
    .
    .
( several statements to do various things such as gathering statistics on the
 database or perhaps setting the checkpoint time.)
    .
    .
    .
   endat


   So I guess it'ld work much like a fork except that it would execute at the
given hour minut and second specified.
   Well, it sounded like a good idea to me.

						Wayne

From ee.ualberta.ca!daum Tue Aug 11 20:11:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "11" "August" "1992" "20:03:46" "-0700" "Ryan Daum" "daum@ee.ualberta.ca" nil "25" "Re: server addition" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Tue, 11 Aug 1992 20:11:49 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11904>; Tue, 11 Aug 1992 20:10:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11897>; Tue, 11 Aug 1992 20:08:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 11 Aug 1992 20:05:04 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11904>; Tue, 11 Aug 1992 20:04:23 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11917>; Tue, 11 Aug 1992 20:03:58 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA24367; Tue, 11 Aug 92 21:03:47 -0600
Full-Name: Ryan Daum
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD00217F21
In-Reply-to: "<9208120052.AA28517@Seagull.Tucson.AZ.US>; from \"Wayne E. Bouchard\" at Aug 11, 92 5:52 pmX@UGA"
Message-ID: <92Aug11.200358pdt.11917@alpha.xerox.com>
Date:	Tue, 11 Aug 1992 20:03:46 -0700
From:	Ryan Daum <daum@ee.ualberta.ca>
To:	moo-cows.PARC@xerox.com
Subject: Re: server addition


>    at(15:00:00)
>     .
>     .
>     .
> ( several statements to do various things such as gathering statistics on the
>  database or perhaps setting the checkpoint time.)
>     .
>     .
>     .
>    endat
> 
> 
	This is how CoolMUD does it's forking, but I really don't see the difference.

	Why not do something like?

	fork(time()+(15*60))
		your statements
	endfork

	It amounts to the same thing.




From morticia.cnns.unt.edu!cluther Wed Aug 12 16:41:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "12" "August" "1992" "15:51:11" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" "<199208122251.AA12819@morticia.cnns.unt.edu>" "13" "New Moo" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Wed, 12 Aug 1992 16:41:53 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11984>; Wed, 12 Aug 1992 16:40:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12000>; Wed, 12 Aug 1992 16:36:48 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Wed, 12 Aug 1992 16:25:31 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11988>; Wed, 12 Aug 1992 16:25:05 PDT
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11992>; Wed, 12 Aug 1992 15:51:12 PDT
Received: by morticia.cnns.unt.edu id AA12819
  (5.65c/IDA-1.4.4 for moo-cows.PARC@xerox.com); Wed, 12 Aug 1992 17:51:11 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD00218D6C
Message-ID: <199208122251.AA12819@morticia.cnns.unt.edu>
Date:	Wed, 12 Aug 1992 15:51:11 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows.PARC@xerox.com (Moo Cows)
Subject: New Moo

Is the next release of the server going to be the disk-based version?  I
ask because we have run up against the "impossible" barrier here on the 
GodNet - that is, under 80mb of RAM the GN can no longer function 
without dire affect to the rest of the system (the GN chews up about 60mb
of memory).  

Our choices are 1) wait for a disk-based version of moo, or 2) abandon moo.

Inquiring minds want to know.

-- 
Clay Luther
cluther@morticia.cnns.unt.edu

From parc.xerox.com!pavel Thu Aug 13 09:55:26 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "13" "August" "1992" "09:39:22" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "22" "Re: New Moo" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Thu, 13 Aug 1992 09:55:16 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11569>; Thu, 13 Aug 1992 09:54:21 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11592>; Thu, 13 Aug 1992 09:50:12 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 13 Aug 1992 09:40:54 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11569>; Thu, 13 Aug 1992 09:40:30 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11585>; Thu, 13 Aug 1992 09:39:49 PDT
Received: by lambda.parc.xerox.com id <58372>; Thu, 13 Aug 1992 09:39:36 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00219713
In-Reply-to: <199208122251.AA12819@morticia.cnns.unt.edu>
Message-ID: <92Aug13.093936pdt.58372@lambda.parc.xerox.com>
References: <199208122251.AA12819@morticia.cnns.unt.edu>
Date:	Thu, 13 Aug 1992 09:39:22 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	cluther@morticia.cnns.unt.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: New Moo

> Date:	Wed, 12 Aug 1992 15:51:11 -0700
> From:	Clay Luther <cluther@morticia.cnns.unt.edu>
> 
> Is the next release of the server going to be the disk-based version?

I'm afraid not.  The current schedule of releases looks like this:

	What						When
	----						----
	Major cleanup of the compiler, decompiler,	Friday or Monday
	  and interpreter; regular expression
	  matching and substitution support; several
	  minor improvements. (Version 1.6.0)

	Reference-counting replaces value-copying in	End of August
	  the interpreter for major speed-up;
	  support for many kinds of `networks',
	  including multi-user non-networking and
	  single-user operation.  (Version 1.7.0?)

	Disk-based database for major decrease in	End of September
	  memory usage.  (Version 1.8.0?)

From oxy.edu!t_pascal Thu Aug 13 14:47:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "13" "August" "1992" "14:39:59" "-0700" "Clarence Regis Wilson" "t_pascal@oxy.edu " nil "53" "Utilities" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Thu, 13 Aug 1992 14:47:33 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11946>; Thu, 13 Aug 1992 14:46:35 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11934>; Thu, 13 Aug 1992 14:43:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 13 Aug 1992 14:37:39 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11934>; Thu, 13 Aug 1992 14:37:05 PDT
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <11802>; Thu, 13 Aug 1992 14:27:32 PDT
Received: by gate.oxy.edu (4.0/SMI-4.0)
	id AA19905; Thu, 13 Aug 92 14:27:30 PDT
Organization: Occidental College, Los Angeles, CA  90041
X-NS-Transport-ID: 08002008D0FD00219D85
Message-ID: <234755@tiger.oxy.edu>
Date:	Thu, 13 Aug 1992 14:39:59 -0700
From:	t_pascal@oxy.edu (Clarence Regis Wilson)
To:	moo-cows.PARC@xerox.com
Apparently-To: xerox.com!moo-cows
Subject: Utilities


I love the new LambdaCore database, very *very* nice.  I have one question
and then one suggestion.

Q:  $match_utils has various match algorithms, giving the ability to type
"look at first box", "look at my box" etc.  I seem to remember in the old
database that they were considered "experimental" and would be added later...
Have they been added?  Will they?  I tried fooling with it, but there's
a lot to change and decided to leave it up to others :)  Is there a plan, or
strategy with regards to better multiple and partial matching?


Question: Speaking of utilities, there are quite a few of them sitting under
$root_class.  In the old db, I created a useless object, child of $root_class,
and then moved all the utilities under it.  It cleans the root children quite a
bit, and also (as a side bonus) cleans some of the #0 properties. Like so:

@create $root_class named Generic Utility
@prop $util <object number of above>
@chparent $string_utils to $util
...etc...
@prop $util.string $string_utils
...etc...
@rmprop $string_utils
...etc...

And then fixed any verbs which called $*_utils.  It was some work, but it
finally panned out, and cleaned up quite a bit.  To call $string_utils, you
just reverse the categorizing, much like netnews. Instead of "string, utils"
you think "utils, string" or "utils, lists".  Also, if $util.string wants to
call $util.match, it can also say this.match, which isn't as clear at first
glance, but in an inherited environment, is how it can be done.

Anyway, now there's a new db, I'll have to do this over again.	Does any part
this strike anyone as generally useful?  The $util class makes a lot of sense,
at least to me, even though it's only a dummy and prettifier.  Oh well.

Have fun :)


	   T. Pascal
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    "Like no cheese I've tasted before, Gromit."  -From "A Grand Day Out"
    "There will always be prayer in school as long as there are final
     exams" -Unknown
    "Absolutely unstoppable, then, so sell it on the street!" -Thomas Robertson
    "I don't like your .sig either." -Someone's .sig
    "You're going to die soon, too, but in the mean time you eat!"
					    -Paul Bowles
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
       t_pascal@{cub.math,jaguar.math,bobcat,tiger,gate}.oxy.edu
T. Pascal and Associates is an equal-opportunity hacking and programming
corporation.  Send inquiries and/or resumes to one of the above addresses.

From parc.xerox.com!pavel Thu Aug 13 18:59:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "13" "August" "1992" "18:49:40" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "37" "Server version 1.6.0 released" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Thu, 13 Aug 1992 18:58:55 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12066>; Thu, 13 Aug 1992 18:58:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12060>; Thu, 13 Aug 1992 18:55:37 PDT
Received: by lambda.parc.xerox.com id <58374>; Thu, 13 Aug 1992 18:49:41 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0021A23A
Message-ID: <92Aug13.184941pdt.58374@lambda.parc.xerox.com>
Date:	Thu, 13 Aug 1992 18:49:40 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Server version 1.6.0 released

Version 1.6.0 of the LambdaMOO server is now available for anonymous FTP from
host `parcftp.xerox.com', file `pub/MOO/LambdaMOO-1.6.0.tar.Z'; don't forget to
use `binary' mode...

This release is mostly a clean-up release, getting the server in better shape
for the next two major improvements: ref-counting and a disk-based database.
We did manage to include a few user-visible enhancements along the way,
however.

The updated version of the LambdaMOO Programmer's Manual is not yet available;
we hope to put it out for FTP by Monday.

Enjoy!

	Pavel/Haakon and Phil/Dren

>From ChangeLog.txt:

Version 1.6.0, 14 August 1992
-- Changed MOO-code parser to generate the old version 1.3 program-
   representation based on abstract syntax trees.  These syntax trees are then
   translated to vectors of bytecodes.  This is much cleaner and easier to
   understand than the old method; perhaps surprisingly, it also appears to be
   significantly faster, too.  (Version 1.5.21)
-- Added support for compilation on MIPS SVR3 machines.
-- Added support for a remote `checkpoint-request' signal (SIGUSR2), analogous
   to the existing `shutdown-request' signal (SIGUSR1).
-- Changed unparser to first convert bytecodes to trees and then use output
   routines from version 1.3 of the server.  Same for line numbers.
-- Error tracebacks now include line numbers for all frames on stack.
   (Version 1.5.24)
-- Cleaned up interpreter code.
-- Added sqrt() and server_log() built in functions (Version 1.5.25)
-- All built-in function registration procedures are now located in one list,
   so it is easier to add new ones.
-- Added match(), rmatch(), and substitute() built-in functions to handle
   regular expression searches. (Version 1.6.0)

From computing-maths.cardiff.ac.uk!Andrew.Wilson Fri Aug 14 05:47:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "14" "August" "1992" "05:38:11" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "104" "Inter-MOO communication IV" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 14 Aug 1992 05:47:49 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11749>; Fri, 14 Aug 1992 05:46:18 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11739>; Fri, 14 Aug 1992 05:44:04 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Fri, 14 Aug 1992 05:39:42 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11723>; Fri, 14 Aug 1992 05:39:14 PDT
Via: uk.ac.cardiff.computing-maths; Fri, 14 Aug 1992 13:38:26 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <17176-0@sentinel.cm.cf.ac.uk>; Fri, 14 Aug 1992 13:38:18 +0100
X-NS-Transport-ID: 08002008D0FD0021A73F
Message-ID: <9208141238.AA12175@opal.cm.cf.ac.uk>
Date:	Fri, 14 Aug 1992 05:38:11 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-Cows@parc.xerox.com
Subject: Inter-MOO communication IV


Hi,

	for the past two weeks I've been working on the implementation
of a networking system which allows MOOs to communicate with each other.
The networking system is a necessary precursor to the implementation of
VROOMs and to the implementation of a distributed object environment which
would (I hope) eventually allow objects which physically exist on different MOO
sites to interact with each other.


THE DEVELOPEMENT ENVIRONMENT

The networking system has been developed using version 1.5.0 of the MOO server
and the LambdaCore-13Dec91.db database from parc.xerox.com.  I have not yet
looked at version 1.6.0 of the server or the latest LambdaCore.  The hardware
comprises a heard of Sun workstations connected over ethernet.  I've had
six of them interconnected, one MOO per machine with no problems.


ABOUT THE NETWORK

The networking system permits any number of MOO sites to interconnect
in an arbitrary manner.  Connected sites communicate by sending coded
'packets' of data to each other.  A simple command permits any verb to
receive responses to 'requests' it makes to the network.  For example the
code fragment:

	Topology = TheNetwork:request("NETWORK_TOPOLOGY");
	player:tell("Network Topology = ", Topology);

asks the network to return a text string indicating the interconnectedness
(Big word?  Big concept!) of the network.  Put simply (very simply!),
the request is serviced by asking each connected site in turn to
list all the connections it has made to any other site.  A typical response
for my domain would be:

	Network Topology = opal->sapphire sapphire->opal sapphire->ruby ruby->sapphire

Where the '->'s indicate the direction of data flow in the network. This response
is for a network consisting of the three sites, opal, sapphire and ruby.
Opal has a two-way connection with sapphire and sapphire has a two-way
connection with ruby.
	With a network of this form, where opal is not directly connected to
ruby, any requests made at opal are relayed to ruby by firstly passing them
through sapphire and then on to ruby. The ability of a site to relay messages
which are not intended for that site enables complex networks to be designed.
Try drawing this network for the sites a, b, c, d and e, for example:

	a->b
	b->c
	b->d
	c->e
	d->e
	e->a

In this case all the connections are one-way but the networking system can handle
this and all requests made to the network can still be serviced.
	The network has a built in fail-safe to stop 'lost' packets of
information circulating throughout the network for ever. In addition, requests
made to the network will eventually time-out to prevent the calling verb from
hanging indefinately when the request can not be serviced due to extreme
net-lag or because of a crash at one of the MOO sites.


VROOMS (Ring the bells, ring the bells!  Let there be light! etc.)

	They work.  I know I've said as much before but I can prove it
now.


DOES ANYBODY CARE?

	The Inter-MOO network experiment is now in a stable enough state
to involve other sites.  I'd like to hear from responsible people at MOO sites
who would be interested in getting involved with setting up an experimental
long-haul network between my domain at Cardiff University in Wales and their own
site.  Your interest, though much appreciated, would not guarantee that your
site would be involved at an early stage.


WHAT I NEED TO KNOW

	Let me know who you are and what position you hold on your MOO and
give me the MOO's IP address.  If I can't visit you from Cardiff then the
network won't be able to visit you either!


WHAT YOU NEED TO KNOW (For the time being.)

	Your site's server MUST allow the open_network_connection() built-in
to be called. Ideally you should be a wizard because there'll be a LOT to do to
get the system up and running. You'll also need physical access to the machine
your MOO runs on because you'll need to keep an eye on the state of the
(internet) network and things like cpu usage.  If you know about 'netstat' and
'top' in UNIX then you probably know enough.


Please post any questions you may have to MOO-Cows@parc.xerox.com so
that we can all join in.

Thanks,
	Andrew "Nope, there's absolutely NO WAY it's going to work!"
	Wilson.

From parc.xerox.com!pavel Fri Aug 14 11:05:50 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "14" "August" "1992" "10:54:56" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "13" "Server version 1.6.1 released" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 14 Aug 1992 11:05:44 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11749>; Fri, 14 Aug 1992 11:03:53 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11783>; Fri, 14 Aug 1992 11:00:33 PDT
Received: by lambda.parc.xerox.com id <58376>; Fri, 14 Aug 1992 10:55:07 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0021AC8D
Message-ID: <92Aug14.105507pdt.58376@lambda.parc.xerox.com>
Date:	Fri, 14 Aug 1992 10:54:56 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Server version 1.6.1 released

(*sigh*)

Oh, well, it didn't take very long for someone to trip over a bug in the new
regular-expression stuff we stole from the GNU project.  It seems there was a
little tiny off-by-one error in their code that would crash the server if ever
an rmatch() operation failed.

Suffice it to say that the bug is fixed in 1.6.1, now available for FTP from
the usual place.

Sorry for the bad code (and our lack of sufficient testing...),

	Pavel/Haakon and Phil/Dren

From cs.stanford.edu!crew Fri Aug 14 12:30:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "14" "August" "1992" "12:23:39" "-0700" "Roger Crew" "crew@cs.stanford.edu" nil "18" "Re: Utilities" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 14 Aug 1992 12:30:54 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11813>; Fri, 14 Aug 1992 12:30:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11830>; Fri, 14 Aug 1992 12:28:47 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Fri, 14 Aug 1992 12:24:05 -0700
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11575>; Fri, 14 Aug 1992 12:23:31 PDT
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA07996; Fri, 14 Aug 92 12:23:40 PDT
X-NS-Transport-ID: 08002008D0FD0021AE81
Message-ID: <9208141923.AA07996@Xenon.Stanford.EDU>
Date:	Fri, 14 Aug 1992 12:23:39 -0700
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: Utilities

t_pascal@oxy.edu (Clarence Regis Wilson) writes:
>   Q:  $match_utils has various match algorithms, giving the ability to type
>   "look at first box", "look at my box" etc.  I seem to remember in the old
>   database that they were considered "experimental" and would be added later.
>   Have they been added?  Will they?  

The main problem is that these were written quite some time ago, before the
protocols for object matching were ironed out to the extent that they are
now.  In particular, they were written before the distinction between :match
and :match_object was terribly clear --- see `help object-matching'
(in $core_help) for details.

Harmonizing #3879 (G7's matching room which also happens to be the main
customer of $match_utils) with the current core (not only the
:match/:match_object convention but also the new :huh conventions as well) is
probably worth doing, but I haven't had a chance to really look at what this
involves yet --- if there are lots of :match/:match_object verbs on RPG
rooms, we're probably hosed.

From media-lab.media.mit.edu!asb Fri Aug 14 13:41:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "14" "August" "1992" "13:33:10" "-0700" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "12" "dream hardware/minimal hardware" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Fri, 14 Aug 1992 13:41:14 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11835>; Fri, 14 Aug 1992 13:39:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11852>; Fri, 14 Aug 1992 13:38:04 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Fri, 14 Aug 1992 13:33:33 -0700
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11806>; Fri, 14 Aug 1992 13:33:13 PDT
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA29676; Fri, 14 Aug 92 16:33:10 -0400
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD0021B00D
In-Reply-to: "Your message of \"Fri, 14 Aug 92 05:38:11 PDT.\"
             <9208141238.AA12175@opal.cm.cf.ac.uk>VQL
	M"
Message-ID: <9208142033.AA29676@media-lab.mit.edu>
Date:	Fri, 14 Aug 1992 13:33:10 -0700
From:	asb@media-lab.media.mit.edu
To:	MOO-Cows@parc.xerox.com
cc:	asb@media-lab.media.mit.edu
Subject: dream hardware/minimal hardware


I'm thinking of starting a MOO.
Since DEC has kindly agreed to give my lab quite a bit of new 
equipment, I'd like to know what I should ask for.  What is 
the dream machine, and what is the minimum?  How will the
requirements change after MOO goes disk based?

I was thinking of asking for a Decstation 5000 with 128 Mb RAM
and 1 Gb hard drive.  Or should I ask for something more?  :-)
Anything else I need to go with that? 

-- Amy

From ee.ualberta.ca!daum Sat Aug 15 20:24:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "15" "August" "1992" "20:17:14" "-0700" "Tanya Louise Daum" "daum@ee.ualberta.ca" nil "16" "Object matching and programmer privilages" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 15 Aug 1992 20:24:49 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11938>; Sat, 15 Aug 1992 20:24:34 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11936>; Sat, 15 Aug 1992 20:21:55 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 15 Aug 1992 20:18:35 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11936>; Sat, 15 Aug 1992 20:18:14 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11937>; Sat, 15 Aug 1992 20:17:30 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA19214; Sat, 15 Aug 92 21:17:14 -0600
X-NS-Transport-ID: 08002008D0FD0021BBD5
Message-ID: <92Aug15.201730pdt.11937@alpha.xerox.com>
Date:	Sat, 15 Aug 1992 20:17:14 -0700
From:	Tanya Louise Daum <daum@ee.ualberta.ca>
To:	MOO-cows.PARC@xerox.com
Subject: Object matching and programmer privilages

One thing that *really* TICKs me off about the built in MOO parser is the way a
total non-programmer can do look #xxx or look $xxx and see the object.  I know,
I could hack #1:look_self, etc. to make sure that it is in the location, and
everything, but that, to me, seems like a huge amount of time (just ask the
wizards at GodNet)

In an RPG system, you don't want people throwing object numbers around.  What
I'd like to see, in the next release, is a compile time option that lets you
specify whether you'd like non-programmers be able to specify object numbers on
the command line.  A simple call to is_programmer in the matching routines to
prevent things like this would be really nice.

Alterntively, I wouldn't mind seeing all object matching moved in-db.  Parsing
in-db is nice, but my main concern is with object matching.



From computing-maths.cardiff.ac.uk!Andrew.Wilson Sun Aug 16 07:02:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "16" "August" "1992" "06:51:45" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "17" "" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 16 Aug 1992 07:02:04 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12004>; Sun, 16 Aug 1992 07:00:55 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12002>; Sun, 16 Aug 1992 06:59:11 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Sun, 16 Aug 1992 06:53:00 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11945>; Sun, 16 Aug 1992 06:52:35 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11945>; Sun, 16 Aug 1992 06:51:57 PDT
Via: uk.ac.cardiff.computing-maths; Sun, 16 Aug 1992 14:51:52 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <06319-0@sentinel.cm.cf.ac.uk>; Sun, 16 Aug 1992 14:51:48 +0100
X-NS-Transport-ID: 08002008D0FD0021BD59
Message-ID: <9208161351.AA01444@sapphire.cm.cf.ac.uk>
Date:	Sun, 16 Aug 1992 06:51:45 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-cows.PARC@xerox.com



Hi,
	an update on the state of the MOO networking system I'm developing.


	The system no longer requires that all sites have access to
the open_network_connection() built-in.  I had a chat with yduJ about
network security and the like, and from that I've decided to extend the
system to allow connections to be made without using o_n_c().
Interestingly, LambdaMOO and most other commercially sited MOOs don't have
o_n_c() anyway.  For the system to work now, at least one site in the
network HAS to have o_n_c() callable.  Guess who's.

Cheers,
	Andrew Wilson ( Networker @ LambdaMOO ).


From miavx1.acs.muohio.edu!CJONES Sun Aug 16 14:05:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "16" "August" "1992" "13:43:00" "-0700" "CJONES@miavx1.acs.muohio.edu" "CJONES@miavx1.acs.muohio.edu" nil "38" "UNIX newbie needs assistance" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 16 Aug 1992 14:05:25 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12135>; Sun, 16 Aug 1992 14:03:37 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12136>; Sun, 16 Aug 1992 14:02:11 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Sun, 16 Aug 1992 13:48:04 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12132>; Sun, 16 Aug 1992 13:47:35 PDT
Received: from miavx1 ([134.53.2.10]) by alpha.xerox.com with SMTP id <12132>; Sun, 16 Aug 1992 13:47:05 PDT
Received: from MIAVX1.ACS.MUOHIO.EDU by MIAVX1.ACS.MUOHIO.EDU (PMDF #12251) id
 <01GNNMV9A4LS94GMK1@MIAVX1.ACS.MUOHIO.EDU>; Sun, 16 Aug 1992 16:43 EDT
X-VMS-To: IN%"moo-cows.parc@xerox.com"
X-VMS-Cc: CJONES
X-NS-Transport-ID: 08002008D0FD0021BEF5
Message-ID: <01GNNMV9A4LS94GMK1@MIAVX1.ACS.MUOHIO.EDU>
Date:	Sun, 16 Aug 1992 13:43:00 -0700
From:	CJONES@miavx1.acs.muohio.edu
To:	moo-cows.parc@xerox.com
Subject: UNIX newbie needs assistance

I'm new to UNIX and have tried to compile the MOO server (versions 1.5.9
and 1.6.1) on an Ultrix V4.2 (Rev. 96) MicroVAX II platform.  I'm using
CC (no GCC on this machine) and believe that I have the Makefile properly
configured but still receive the following error.


apsvax.aps.muohio.edu> make
cc -g -DMOO -DUSE_RANDOM -DUSE_POSIX -DUSE_SYSTEM_MALLOC -Dconst= -c ast.c
"./structures.h", line 131: syntax error
"./structures.h", line 139: syntax error
"./structures.h", line 139: warning: old-fashioned initialization: use =
"./structures.h", line 139: warning: undeclared initializer name program
"./structures.h", line 139: illegal indirection
"./structures.h", line 139: illegal initialization
"./structures.h", line 140: cannot recover from earlier errors: goodbye!
*** Error code 1

Stop.
apsvax.aps.muohio.edu>


Is there something I've overlooked?  I'll be the first to admit that I know
next to nothing about UNIX and I'm not a guru at C either, but the code
looks fine and other people are using it without trouble.

The MOO is more or less an experiment for me on this platform.  It's just
there so I can play around with it on a UNIX box and then delete it when
the diskspace gets tight, so it's no biggie.  I'm still puzzled, though.

Anything, ranging from RTFM to a solution would be greatly appreciated..
Thanks.

--
Oates                              cjones@miavx1.acs.muohio.edu
                                   cj5jsanu@miamiu.bitnet
"When you install OS/2 2.0 you put the virtual reality hood on the
 pit bull.  The question is, who'll take it off?" - Jim Jones


From computing-maths.cardiff.ac.uk!Andrew.Wilson Sun Aug 16 20:22:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "16" "August" "1992" "20:03:43" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "12" "Inter-MOO Communication XXXXXVIICI" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 16 Aug 1992 20:22:07 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12162>; Sun, 16 Aug 1992 20:21:41 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11995>; Sun, 16 Aug 1992 20:19:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Sun, 16 Aug 1992 20:05:26 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12162>; Sun, 16 Aug 1992 20:04:58 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <12164>; Sun, 16 Aug 1992 20:04:29 PDT
Via: uk.ac.cardiff.computing-maths; Mon, 17 Aug 1992 04:03:53 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <14140-0@sentinel.cm.cf.ac.uk>; Mon, 17 Aug 1992 04:03:50 +0100
X-NS-Transport-ID: 08002008D0FD0021C071
Message-ID: <9208170303.AA02113@sapphire.cm.cf.ac.uk>
Date:	Sun, 16 Aug 1992 20:03:43 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-cows.PARC@xerox.com
Subject: Inter-MOO Communication XXXXXVIICI



Hi,
	I've been told I talk too much. So here it is briefly.

The network between LambdaMOO and CardiffMOO went on-line this morning.  If any
other MOO sites want in on the happeningest thing since the mini-skirt then
come and talk to me.

Ta,
	Networker @ LambdaMOO (Andrew.Wilson @ IRL)


From casbah.acns.nwu.edu!hpa Mon Aug 17 12:23:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "17" "August" "1992" "12:15:18" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "55" "Re: Object matching and programmer privilages" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 17 Aug 1992 12:23:08 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11586>; Mon, 17 Aug 1992 12:21:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11587>; Mon, 17 Aug 1992 12:18:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 17 Aug 1992 12:16:09 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11571>; Mon, 17 Aug 1992 12:15:42 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA17550; Mon, 17 Aug 92 14:15:19 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0021E0AB
In-Reply-to: "<92Aug15.201730pdt.11937@alpha.xerox.com>; from \"Tanya Louise Daum\" at Aug 15, 92 8:17 pm"
Message-ID: <9208171915.AA17550@casbah.acns.nwu.edu>
Date:	Mon, 17 Aug 1992 12:15:18 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	daum@ee.ualberta.ca (Tanya Louise Daum)
cc:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: Re: Object matching and programmer privilages
Reply-to: hpa@nwu.edu

Here is a patch that *seems* to take care of the problem for out-of-db
matching.  It is rather untested, and of course you'll want to change
$match_utils if you are using LambdaCore, but...

cd to your LambdaMOO 1.6.1 source directory and type:

	patch -p0 < thisfile

[If you don't have patch get it from aeneas.mit.edu]

then edit the DEFS line in your Makefile to include -DNO_PL_NUM_MATCH and
make.

	/hpa


*** src1.6.1/Makefile	Fri Aug 14 15:47:05 1992
--- Makefile	Sun Aug 16 00:20:00 1992
***************
*** 47,52 ****
--- 47,56 ----
  #			recent checkpoint.  The log is flushed whenever a
  #			checkpoint is successfully begun and is dumped into the
  #			server log when and if the server panics.
+ #
+ # -DNO_PL_NUM_MATCH     Disallows players from using object numbers in
+ #                       commands; parser will not recognize object numbers
+ #                       typed in by non-programmers.
  
  # These definitions work for SunOS 4.1.1, IRIX4.0, and DEC/MIPS Ultrix 4.2.
  #DEFS = -DUSE_RANDOM -DUSE_POSIX
*** src1.6.1/match.c	Tue Aug 11 12:02:19 1992
--- match.c	Sun Aug 16 00:21:20 1992
***************
*** 91,96 ****
--- 91,102 ----
  	return NOTHING;
      if (name[0] == '#') {
  	char   *p;
+ 
+ #ifdef NO_PL_NUM_MATCH
+ 	if ( !is_programmer(player) )
+ 	  return FAILED_MATCH;
+ #endif
+ 
  	Objid	r = strtol(name + 1, &p, 10);
  
  	if (*p != '\0' || !retrieve(r))


-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
Seeg??  I don't need no goddamn seeg!

From stony-brook.scrc.symbolics.com!yduJ Mon Aug 17 12:40:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "17" "August" "1992" "12:37:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "14" "Re: Object matching and programmer privilages" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 17 Aug 1992 12:40:09 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11625>; Mon, 17 Aug 1992 12:39:38 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11637>; Mon, 17 Aug 1992 12:37:56 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 17 Aug 1992 12:36:14 -0700
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11637>; Mon, 17 Aug 1992 12:35:39 PDT
Received: from AVOCADO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1125757; 17 Aug 1992 15:32:59-0400
X-NS-Transport-ID: 08002008D0FD0021E104
In-Reply-to: <9208171915.AA17550@casbah.acns.nwu.edu>
Message-ID: <19920817193739.6.YDUJ@AVOCADO.SCRC.Symbolics.COM>
Date:	Mon, 17 Aug 1992 12:37:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	hpa@nwu.edu, daum@ee.ualberta.ca
cc:	moo-cows@parc.xerox.com
Subject: Re: Object matching and programmer privilages

+ # -DNO_PL_NUM_MATCH     Disallows players from using object numbers in
+ #                       commands; parser will not recognize object numbers
+ #                       typed in by non-programmers.


Hmmm.  Now that you've already done it...  I would suggest that better
semantics might be to disallow non-progs from using object numbers for
objects that they don't own...  Otherwise they might be screwed after
some creation command that put the object in #-1; no way to recover it.

Possibly this issue should be tabled though, until we get real in-db
parsing, since your purposes were for an RPG mud, and players won't be
creating objects in a strict RPG setting.
							yduJ

From parc.xerox.com!pavel Mon Aug 17 16:43:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "17" "August" "1992" "16:33:16" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "29" "Re: dream hardware/minimal hardware" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 17 Aug 1992 16:42:57 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11671>; Mon, 17 Aug 1992 16:42:31 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11727>; Mon, 17 Aug 1992 16:36:36 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 17 Aug 1992 16:33:56 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11729>; Mon, 17 Aug 1992 16:33:33 PDT
Received: by lambda.parc.xerox.com id <58372>; Mon, 17 Aug 1992 16:33:25 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0021E5D8
In-Reply-to: <9208142033.AA29676@media-lab.mit.edu>
Message-ID: <92Aug17.163325pdt.58372@lambda.parc.xerox.com>
References: <9208141238.AA12175@opal.cm.cf.ac.uk>
	<9208142033.AA29676@media-lab.mit.edu>
Date:	Mon, 17 Aug 1992 16:33:16 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	asb@media-lab.media.mit.edu
cc:	MOO-Cows@parc.xerox.com
Subject: Re: dream hardware/minimal hardware

> Date:	Fri, 14 Aug 1992 13:33:10 -0700
> From:	asb@media-lab.media.mit.edu
> 
> I'm thinking of starting a MOO.

Stop now, before it's too late!

Oh, well, since you appear to have your heart set on it...

> Since DEC has kindly agreed to give my lab quite a bit of new 
> equipment, I'd like to know what I should ask for.  What is 
> the dream machine, and what is the minimum?  How will the
> requirements change after MOO goes disk based?

The dream machine has infinite CPU speed and infinite disk space.  The minimum
for a moderately-large place with good backups is about 100 megabytes of disk
and about 32 megabytes of physical memory; the CPU speed will likely be fine no
matter what DEC machine you get.

When the DB goes disk-based, the memory requirements will drop to about 5-10
megabytes and the disk requirements will drop by about a factor of two.

> I was thinking of asking for a Decstation 5000 with 128 Mb RAM
> and 1 Gb hard drive.  Or should I ask for something more?  :-)
> Anything else I need to go with that? 

That'll do you just fine for quite a long time... :-)

	Pavel

From morticia.cnns.unt.edu!cluther Tue Aug 18 07:39:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "18" "August" "1992" "07:26:29" "-0700" "Clay Luther" "cluther@morticia.cnns.unt.edu" nil "29" "Re: dream hardware/minimal hardware (fwd)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 18 Aug 1992 07:38:59 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11786>; Tue, 18 Aug 1992 07:37:15 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11741>; Tue, 18 Aug 1992 07:33:08 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 18 Aug 1992 07:27:41 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11763>; Tue, 18 Aug 1992 07:27:11 PDT
Received: from morticia.cnns.unt.edu ([129.120.4.5]) by alpha.xerox.com with SMTP id <11766>; Tue, 18 Aug 1992 07:26:31 PDT
Received: by morticia.cnns.unt.edu id AA01600
  (5.65c/IDA-1.4.4 for moo-cows.PARC@xerox.com); Tue, 18 Aug 1992 09:26:30 -0500
X-Mailer: ELM [version 2.3 PL8]
X-NS-Transport-ID: 08002008D0FD0021ED6A
Message-ID: <199208181426.AA01600@morticia.cnns.unt.edu>
Date:	Tue, 18 Aug 1992 07:26:29 -0700
From:	Clay Luther <cluther@morticia.cnns.unt.edu>
To:	moo-cows.PARC@xerox.com (Moo Cows)
Subject: Re: dream hardware/minimal hardware (fwd)

Pavel says:

> 
> The dream machine has infinite CPU speed and infinite disk space.  The minimum
> for a moderately-large place with good backups is about 100 megabytes of disk
> and about 32 megabytes of physical memory; the CPU speed will likely be fine no
> matter what DEC machine you get.
> 

I'd have to disagree here on the ram reqs.  The GN is on a machine with 32mb
of physical memory and 57mb of swap.  After 3 months of being open to the
public, the GN's average memory consumption was about 30mbs, doubling 
during server dumps.

Because the machine is not a "mud-only" machine, this caused a lot of
thrashing as other processes vied for ram.  The result was that everything on
morticia slowed down enormously -- during server dumps, the only word to
describe the slowness would be painful.

However, during our long building phase (not open to the public), the moo 
was extremely well-behaved and unobtrusive.  I look forward to the disk-based
scheme soon to be released, as the GN is on haitus until we get that
functionality.



-- 
Clay Luther
cluther@morticia.cnns.unt.edu

From theory.cs.mankato.msus.edu!nop Tue Aug 18 09:38:13 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "18" "August" "1992" "09:30:39" "-0700" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " "<9208181630.AA03575@theory.cs.mankato.msus.edu>" "10" "dream hardware/minimal hardware (fwd)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 18 Aug 1992 09:38:03 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11806>; Tue, 18 Aug 1992 09:36:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11791>; Tue, 18 Aug 1992 09:35:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 18 Aug 1992 09:32:38 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11791>; Tue, 18 Aug 1992 09:32:06 PDT
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11797>; Tue, 18 Aug 1992 09:31:10 PDT
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA03575; Tue, 18 Aug 92 11:30:39 -0500
X-NS-Transport-ID: 08002008D0FD0021EFAA
In-Reply-to: "Clay Luther's message of Tue, 18 Aug 1992 07:26:29 PDT <199208181426.AA01600@morticia.cnns.unt.edu>"
Message-ID: <9208181630.AA03575@theory.cs.mankato.msus.edu>
Date:	Tue, 18 Aug 1992 09:30:39 -0700
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	cluther@morticia.cnns.unt.edu
cc:	moo-cows.PARC@xerox.com
Subject: dream hardware/minimal hardware (fwd)

> I'd have to disagree here on the ram reqs.  The GN is on a machine with 32mb
> of physical memory and 57mb of swap.  After 3 months of being open to the
> public, the GN's average memory consumption was about 30mbs, doubling 
> during server dumps.

I don't mean to reveal my ignorance, but should the fork for the dump
use all this memory on modern systems?  Seems to me that most of the
pages would be shared between the two processes.

---Jonny

From parc.xerox.com!pavel Tue Aug 18 11:52:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "18" "August" "1992" "11:41:51" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "16" "Re: dream hardware/minimal hardware (fwd)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 18 Aug 1992 11:51:57 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11778>; Tue, 18 Aug 1992 11:50:57 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11763>; Tue, 18 Aug 1992 11:47:48 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 18 Aug 1992 11:43:11 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11662>; Tue, 18 Aug 1992 11:42:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11763>; Tue, 18 Aug 1992 11:42:04 PDT
Received: by lambda.parc.xerox.com id <58372>; Tue, 18 Aug 1992 11:41:55 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0021F266
In-Reply-to: <9208181630.AA03575@theory.cs.mankato.msus.edu>
Message-ID: <92Aug18.114155pdt.58372@lambda.parc.xerox.com>
References: <199208181426.AA01600@morticia.cnns.unt.edu>
	<9208181630.AA03575@theory.cs.mankato.msus.edu>
Date:	Tue, 18 Aug 1992 11:41:51 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	nop@theory.cs.mankato.msus.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: dream hardware/minimal hardware (fwd)

> Date:	Tue, 18 Aug 1992 09:30:39 -0700
> From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
> 
> I don't mean to reveal my ignorance, but should the fork for the dump
> use all this memory on modern systems?  Seems to me that most of the
> pages would be shared between the two processes.

Yes, well, you'd like that, but Sun Microsystems (apparently among others) in
its infinite wisdom decided not to implement copy-on-write virtual memory
sharing.  Thus, in order to do the fork, the system does indeed copy the entire
image of the forking process and thus doubles the swap space and physical
memory demand.

Sigh.

	Pavel

From computing-maths.cardiff.ac.uk!Andrew.Wilson Wed Aug 19 21:01:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "19" "August" "1992" "20:54:26" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "22" "Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 19 Aug 1992 21:01:11 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12032>; Wed, 19 Aug 1992 21:00:35 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12036>; Wed, 19 Aug 1992 20:57:43 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Wed, 19 Aug 1992 20:55:02 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <12032>; Wed, 19 Aug 1992 20:54:44 PDT
Via: uk.ac.cardiff.computing-maths; Thu, 20 Aug 1992 04:54:29 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <06834-0@sentinel.cm.cf.ac.uk>; Thu, 20 Aug 1992 04:54:29 +0100
X-NS-Transport-ID: 08002008D0FD00220C48
Message-ID: <9208200354.AA05331@topaz.cm.cf.ac.uk>
Date:	Wed, 19 Aug 1992 20:54:26 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-Cows@parc.xerox.com
Subject: Yawn, VROOMs etc.




Hi,
	erm, well they work, don't they. Don't say I didn't warn you.

Andrew Wilson.  Networker @ LambdaMOO + ChaosMOO + DreaMOO

ps.	LPmuds are going to be able to do this sort of thing soon too I think.

pps.	Is this the sort of thing you want to see in LambdaCore?

ppps.	I appreciate the fact that you're all buisy, but have you got any
	other ideas that could exploit a network.

pppps.	MI or bust I fear.

ppppps.	Love the haircut, is it new?

pppppps.5am, time for bed.

zzzzzzzz

From suna0.cs.uiuc.edu!scott Wed Aug 19 21:28:20 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "19" "August" "1992" "21:23:04" "-0700" "Jay Scott" "scott@suna0.cs.uiuc.edu" "<199208200423.AA20424@sparc7.cs.uiuc.edu>" "9" "built-in parser" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 19 Aug 1992 21:28:09 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12035>; Wed, 19 Aug 1992 21:26:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12037>; Wed, 19 Aug 1992 21:25:18 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Wed, 19 Aug 1992 21:22:53 -0700
Received: from sparc7.cs.uiuc.edu ([128.174.244.117]) by alpha.xerox.com with SMTP id <12037>; Wed, 19 Aug 1992 21:22:25 PDT
Received: by sparc7.cs.uiuc.edu id AA20424
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Wed, 19 Aug 1992 23:23:04 -0500
X-NS-Transport-ID: 08002008D0FD00220C7D
Message-ID: <199208200423.AA20424@sparc7.cs.uiuc.edu>
Date:	Wed, 19 Aug 1992 21:23:04 -0700
From:	Jay Scott <scott@suna0.cs.uiuc.edu>
To:	moo-cows@parc.xerox.com
Subject: built-in parser

Is it easy to hack the server to turn off its built-in parser?
Ideally, it should be a compile-time option.

I ask because it's simple in principle to do all parsing in-database,
but currently this requires you to make sure that all the verbs are
hidden from the built-in parser, so it doesn't short-circuit your own.

	Frand
	scott@cs.uiuc.edu

From netcom.com!frankc Thu Aug 20 01:16:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "01:09:46" "-0700" "Frank Crowell" "frankc@netcom.com " nil "49" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Thu, 20 Aug 1992 01:16:38 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11524>; Thu, 20 Aug 1992 01:15:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11528>; Thu, 20 Aug 1992 01:13:48 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 01:11:19 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11528>; Thu, 20 Aug 1992 01:10:50 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA10150; Thu, 20 Aug 92 01:09:47 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00220DFB
In-Reply-to: "<9208200354.AA05331@topaz.cm.cf.ac.uk>; from \"Andrew Wilson\" at Aug 19, 92 8:54 pmse f"
Message-ID: <9208200809.AA10150@netcom.netcom.com>
Date:	Thu, 20 Aug 1992 01:09:46 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Re: Yawn, VROOMs etc.

> Hi,
> 	erm, well they work, don't they. Don't say I didn't warn you.
> 
> Andrew Wilson.  Networker @ LambdaMOO + ChaosMOO + DreaMOO
Ok, I admit it; I haven't seen a demo yet.

> ps.	LPmuds are going to be able to do this sort of thing soon too I think.
I know that there has been some discussion about having a pub that could
be connected to more that one LPmud; VRooms eliminate a couple 
of concerns:
	1. no character or object transfers
		I won't go into a discussion on the above point,
		but it has been a real concern about any pub that
		could connect to more than one area in same mud
		or if several muds connected to the pub

	2. no  entrance/exit bookkeeping
> 
> pps.	Is this the sort of thing you want to see in LambdaCore?
> 
I don't know about the Core, but VRooms can keep some the various
MOOs connected (maybe also a CoolMUD or two).  Certainly as a minimum,
VRooms should be kept on at least a couple of MOOs and the code stored in 
the ftp archive. Maybe also a Design & Implementation brief at the
MOO Institute (its still ChaosMUD, right?)

> ppps.	I appreciate the fact that you're all buisy, but have you got any
> 	other ideas that could exploit a network.
> 
If whispers are not implemented, I would suggest that area 
be explored.  This would allow sofware agents to carry out some
actions and give the information to a particular person or channel.
(still not sure about pages, tho)

Another possibility is to have a VRoom Workshop (at the MOO Institute
of course); it could present the D & I and allow the participants to
develop their own design briefs, maybe dealing with such areas as:
	1. VRoom and software agents
	2. WallScreen Model (variant from Amy's suggestion of a studio)
	3. Other NeatStuff
	4. Maybe something dealing with NTP (Network Time Protocol)
	5. NeXtStep (hmmm): borader Issues dealing with distributed MOOs
	
> pppps.	MI or bust I fear.
Ok, I give up. What is MI?

-- 
Frank Crowell frankc@netcom.COM
[This Space for Rent]

From unipress.com!joe Thu Aug 20 03:22:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "03:16:40" "-0700" "joe@unipress.com" "joe@unipress.com" nil "21" "COOLMUD 2.0 review" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Thu, 20 Aug 1992 03:22:29 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11550>; Thu, 20 Aug 1992 03:21:40 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11549>; Thu, 20 Aug 1992 03:19:46 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 03:17:10 -0700
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <11545>; Thu, 20 Aug 1992 03:16:52 PDT
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA16126; Thu, 20 Aug 92 06:16:47 EDT
Received: from dot.UniPress.COM by repo.unipress.com (4.1/SMI-4.1/UniPress121791.1)
	id AA05819; Thu, 20 Aug 92 06:16:43 EDT via
X-NS-Transport-ID: 08002008D0FD00220EB8
In-Reply-to: "Your message of \"Sun, 02 Aug 92 16:17:35 PDT.\"
             <9208022317.AA21670@repo.unipress.com>"
Message-ID: <9208201016.AA05819@repo.unipress.com>
Date:	Thu, 20 Aug 1992 03:16:40 -0700
From:	joe@unipress.com
To:	joe@unipress.com
cc:	moo-cows@parc.xerox.com, joe@unipress.com
Subject: COOLMUD 2.0 review


COOLMUD 2.0 is out.  This is obviously the wrong place to be talking about it
but some of the bad things about COOLMUD 1.1 that I mentioned before have gone
away, so to be fair to ghond I figure I should revise my remarks a little bit.

> The database for COOLMUD is still stored in core, and it has no garbage
> collector other than a simple copy-on-reference policy (two problems which
> plague MOO).

Both of these problems are gone now.  Lists and strings have reference counts,
and the disk-based db stuff is in alpha.

> You can get it, along with some cursory, out of date (when I got it) 
> documentation via anonymous ftp from piggy.ucsb.edu.

Still the case for 2.0, but you may have to search around a bit.

SRI SYADASTI SYADAVAKTAVYA SYADASTI SYANNASTI SYADASTI CAVAKTAVYASCA
SYADASTI SYANNASTI SYADAVATAVYASCA SYADASTI SYANNASTI SYADAVAKTAVYASCA

-K*

From computing-maths.cardiff.ac.uk!Andrew.Wilson Thu Aug 20 05:55:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "05:49:35" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "26" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Thu, 20 Aug 1992 05:55:41 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11565>; Thu, 20 Aug 1992 05:54:53 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11567>; Thu, 20 Aug 1992 05:53:16 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 05:51:08 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11564>; Thu, 20 Aug 1992 05:50:45 PDT
Via: uk.ac.cardiff.computing-maths; Thu, 20 Aug 1992 13:49:53 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <14867-0@sentinel.cm.cf.ac.uk>; Thu, 20 Aug 1992 13:49:43 +0100
X-NS-Transport-ID: 08002008D0FD00220FE6
Message-ID: <9208201249.AA00319@topaz.cm.cf.ac.uk>
Date:	Thu, 20 Aug 1992 05:49:35 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-Cows@parc.xerox.com
Subject: Re: Yawn, VROOMs etc.



Hi,

	I've been speaking to Johan Andersson (jna@cd.chalmers.se), who's
the coordinator of software design for the CDLib project at Genesis.
Genesis is LPmuds version of LambdaMOO, it's the original LP site, and CDlib
is LPmud's 'LambdaCore'.  Johan tells me that Genesis can ALREADY send
and receive udp packages (data packets) by making calls to SERVER functions.
i.e. LPmuds have built-ins that can do what my network object can do.  This
means that they're probably a couple of orders of magnitude FASTER than my
MOO code could ever be.  I'm not saying that Johan's work is identical to what
we've been able to acieve with MOO-net BUT it bears enough similarities to make
me think that the time when we will able to network MOOs AND LPmuds together
is not far away.
	They even have the beginnings of a theory about VROOMs!

I'd like to know what you think, seriously, about turning MOO-net into M**-net.


Thanks,
	Andrew Wilson - Networker @ LambdaMOO + DreaMOO + ChaosMOO

ps.	In case it wasn't clear, VROOMs have been installed on the above 3 MOO
	sites.  Drop in sometime if you wan't to learn more about them.  A.


From computing-maths.cardiff.ac.uk!Andrew.Wilson Thu Aug 20 06:44:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "06:38:22" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "71" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Thu, 20 Aug 1992 06:44:33 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11589>; Thu, 20 Aug 1992 06:43:15 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11582>; Thu, 20 Aug 1992 06:41:22 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 06:39:39 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11581>; Thu, 20 Aug 1992 06:39:18 PDT
Via: uk.ac.cardiff.computing-maths; Thu, 20 Aug 1992 14:38:38 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <16146-0@sentinel.cm.cf.ac.uk>; Thu, 20 Aug 1992 14:38:34 +0100
X-NS-Transport-ID: 08002008D0FD0022107A
Message-ID: <9208201338.AA00369@topaz.cm.cf.ac.uk>
Date:	Thu, 20 Aug 1992 06:38:22 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com
Subject: Re: Yawn, VROOMs etc.



Hi,
	Ryan Daum (daum@ee.ualberta.ca) just e-mailed me and I think
you'd all like to hear this.  I said:

> pps.	Is this the sort of thing you want to see in LambdaCore?

And Ryan replied:

>  Well, to tell you the truth, I'd rather see VPLAYERS than VROOMS.  I mean,
>not actually creating a remote player object, but instead "faking" it by
>keeping a database of temporary objects which act like players (perhaps even
>children of $player) but simply have a :tell which sends to the player and
>allow the player to issue commands through an event system of some sort.

>   This is still sketchy in my mind, though.  I wouldn't advocate actually
>letting the player assume a connection on the other MOO.  I'd rather see the
>player given a sort of view "into the world" and some special feature objects
>which let them work in the remote rooms (with In-DB parsing one could
>manipulate objects on the other machine qurtie well, as well)

My reply:

Mmm, I don't quite follow you there.  I'll admit that I've used rather
confusing terminology in the past;  VPLAYERs forinstance, don't exist in
any recognisable for in my networking system.  I was a little confused
when I first mentioned them, and now they refuse to go away!  I DO use
MOO $player objects to maintain the connections between MOOs.  CardiffMOO
on LambdaMOO is a player who does nothing but recieve data-packets from my
MOO in Cardiff, which he then distributes to the network object that 
Networker carries around.
	If I understand you correctly, then YOUR idea of a VPLAYER is rather
like a LambdaMOO puppet, something which can act as the eyes and ears of a 
player on another MOO.  This is CERTAINLY possible, even with the bug-infested
networking system we have at the moment.  And a VPLAYER with no greater
functionality than a LambdaMOO puppet could be designed to operate with
the network.  Good idea.
	As for manipulating objects on other sites, well it is not a trivial
problem.  As you'll soon become aware, the LPmud systems are evolving
something which looks very like MOO-net and I think that it would be 
a good idea to design ways and means of interacting with remote objects
which are not specific to the representation of those objects on the
remote sites to which our M** connects.  In the short term you could certainly
have MOO specific mechanisms.  We could ask your VPLAYERs to 'get ball'
or to ': goes to sleep in the corner.', and your VPLAYERs, @kids of $player,
would do what you asked.  However, what I have in mind is a distributed-object
protocol (A Whaaat?!), by which I mean a global object schema which all
networked sites, MOOs and LPmuds, would agree to use in the design of objects
that they wanted to be available across the network.
	For example, the documents in the LambdaHouse library would be @kids of
$generic-distributed-document and could be read by anyone on an LPmud who was
in the same VROOM.  By adopting a $generic-distributed-<whatever> approach
we, on the MOOs could ensure that only $genric-distributed-<whatever>s
could be accessed by other sites.  This is good for security reasons and means
that all networked sites can SHARE the developement cost (time, memory-space)
of new objects.
	So we have VROOMs to limit the access of other M**s to rooms on our
site, and $genric-distributed-<whatever>s to limit the effect that other M**s
can have on our objects.

Comments?
Donations?
Sympathy?

Andrew Wilson - Networker @ here, there and soon everywhere.






From onet.edu!CAMP!seth Thu Aug 20 09:55:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "05:42:00" "-0700" "seth%CAMP@onet.edu" "seth%CAMP@onet.edu" nil "13" "Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 20 Aug 1992 09:55:49 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11594>; Thu, 20 Aug 1992 09:54:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11632>; Thu, 20 Aug 1992 09:50:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 09:46:39 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11632>; Thu, 20 Aug 1992 09:46:25 PDT
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11620>; Thu, 20 Aug 1992 09:45:43 PDT
Received: from CAMP.Onet.Edu ([141.110.32.5])  for Moo-Cows@Xerox.Com
	by oscsunb.osc.edu (5.65c+KVa/920330.1102) id AA15900; Thu, 20 Aug 1992 12:45:38 -0400
Received: from campgate.onet.edu by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA19475; Thu, 20 Aug 92 12:44:59 EDT
Received: by campgate.onet.edu with Network-Courier
	id <2A93CB87@campgate.onet.edu>; Thu, 20 Aug 92 12:42:47
X-Mailer: Network Courier V2.1a
Encoding: 13 TEXT
X-NS-Transport-ID: 08002008D0FD0022138B
Message-ID: <2A93CB87@campgate.onet.edu>
Date:	Thu, 20 Aug 1992 05:42:00 -0700
From:	seth%CAMP@onet.edu
To:	Moo-Cows.PARC@xerox.com
Subject: Yawn, VROOMs etc.

Andrew Wilson (Networker) sez:

> erm, well they work, don't they. Don't say I didn't warn you.

I'm curious... WHY is this being done? Is it going to stay up (I hope
not)... is it the cause of the really unpleasant lag we've been having
on LambdaMOO so often these days?

I mean, I'm impressed... but isn't this just a ``See, I can do it, so
I did'' thing?

Seth / Blackbriar@various


From parc.xerox.com!pavel Thu Aug 20 10:23:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "10:13:13" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "15" "Re: built-in parser" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 20 Aug 1992 10:23:11 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11619>; Thu, 20 Aug 1992 10:19:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11535>; Thu, 20 Aug 1992 10:17:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Thu, 20 Aug 1992 10:13:52 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11535>; Thu, 20 Aug 1992 10:13:32 PDT
Received: by lambda.parc.xerox.com id <58374>; Thu, 20 Aug 1992 10:13:19 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00221429
In-Reply-to: <199208200423.AA20424@sparc7.cs.uiuc.edu>
Message-ID: <92Aug20.101319pdt.58374@lambda.parc.xerox.com>
References: <199208200423.AA20424@sparc7.cs.uiuc.edu>
Date:	Thu, 20 Aug 1992 10:13:13 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	scott@suna0.cs.uiuc.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: built-in parser

> Date:	Wed, 19 Aug 1992 21:23:04 -0700
> From:	Jay Scott <scott@suna0.cs.uiuc.edu>
> 
> Is it easy to hack the server to turn off its built-in parser?
> Ideally, it should be a compile-time option.
> 
> I ask because it's simple in principle to do all parsing in-database,
> but currently this requires you to make sure that all the verbs are
> hidden from the built-in parser, so it doesn't short-circuit your own.

It would be easy to add a compile-time option that would send all user commands
to some particular verb, such as #0:do_command(commandstr); is that what you
want?

	Pavel/Haakon

From computing-maths.cardiff.ac.uk!Andrew.Wilson Thu Aug 20 10:40:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "10:31:47" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "45" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Thu, 20 Aug 1992 10:40:17 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11628>; Thu, 20 Aug 1992 10:38:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11620>; Thu, 20 Aug 1992 10:36:19 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Thu, 20 Aug 1992 10:34:16 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11615>; Thu, 20 Aug 1992 10:33:44 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11600>; Thu, 20 Aug 1992 10:32:52 PDT
Via: uk.ac.cardiff.computing-maths; Thu, 20 Aug 1992 18:32:25 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <21743-0@sentinel.cm.cf.ac.uk>; Thu, 20 Aug 1992 18:32:01 +0100
X-NS-Transport-ID: 08002008D0FD00221484
Message-ID: <9208201731.AA00620@topaz.cm.cf.ac.uk>
Date:	Thu, 20 Aug 1992 10:31:47 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	Moo-Cows.PARC@xerox.com
Subject: Re: Yawn, VROOMs etc.



Mmmm,
	Seth / Blackbriar@various says:

>I'm curious... WHY is this being done? Is it going to stay up (I hope
>not)... is it the cause of the really unpleasant lag we've been having
>on LambdaMOO so often these days?

>I mean, I'm impressed... but isn't this just a ``See, I can do it, so
>I did'' thing?

	You're lucky because I'm busy atm so this'll have to be brief.

1.	I don't run LambdaMOO so I don't know what tasks on the system
are causing the lag.  Seriously though, yduJ?, can you give us an idea of
why LambdaMOO's so slow.  If it IS my system that's the cause, I'll remove it
immediately and until I've fixed it.  I don't see why my (alleged) incompetence
should be allowed to punish the rest of you.

2.	Ok, back to basics, yeah?  There's the network, ok?  I mean the REAL
network, not just the toy that I'm playing with, and it's full of useful gadgets
that anyone can log into and use.  I think it would be neat to be ABLE to
mess with those gadgets from LambdaMOO.  Then consider how many MOOs there are
in the world, mmmm... seven is it?  Or is it eight?  Fine, now consider
how many LPmuds there are in the world.  Let's count them shall we.
	One, two, three, four, five, six, seven, eight, nine, ten, eleven,
twelve.  Still with me?  Ok, thirteen, fourteen, fifteen, sixteen, seventeen.
Mmmm, what's after seventeen, er, eighteen?  Eighteen, nineteen, twenty,
twenty one, twenty two...  Gee there's a lot of LPmuds isn't there?!
Wow, just think of all that software on all those sites that we JUST CAN'T USE.
Just think of all those people on those sites that WE JUST CAN'T TALK TO.
Kinda, makes you wonder doesn't it?

3.	I would value any CONSTRUCTIVE comments you have to offer, but I can't
do very much to improve matters if all I get are unspecific opinions.

>(I hope not).

Not too much meat on that one I'm afraid, can you give us some more to go on?

Andrew Wilson - Networker @ his wit's end.

ps.	Help me.  I don't know what you need. 


From onet.edu!CAMP!seth Thu Aug 20 11:11:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "06:58:00" "-0700" "seth%CAMP@onet.edu" "seth%CAMP@onet.edu" nil "77" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 20 Aug 1992 11:11:03 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11617>; Thu, 20 Aug 1992 11:09:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11580>; Thu, 20 Aug 1992 11:07:31 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 11:02:41 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11522>; Thu, 20 Aug 1992 11:02:14 PDT
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11530>; Thu, 20 Aug 1992 11:01:17 PDT
Received: from CAMP.Onet.Edu ([141.110.32.5])  for Moo-Cows@Xerox.Com
	by oscsunb.osc.edu (5.65c+KVa/920330.1102) id AA17296; Thu, 20 Aug 1992 14:01:12 -0400
Received: from campgate.onet.edu by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA19686; Thu, 20 Aug 92 14:00:33 EDT
Received: by campgate.onet.edu with Network-Courier
	id <2A93DD3C@campgate.onet.edu>; Thu, 20 Aug 92 13:58:20
X-Mailer: Network Courier V2.1a
Encoding: 77 TEXT
X-NS-Transport-ID: 08002008D0FD00221537
Message-ID: <2A93DD3C@campgate.onet.edu>
Date:	Thu, 20 Aug 1992 06:58:00 -0700
From:	seth%CAMP@onet.edu
To:	Moo-Cows.PARC@xerox.com
Subject: Re: Yawn, VROOMs etc.

Networker:

> I don't run LambdaMOO so I don't know what tasks on the system
> are causing the lag.  Seriously though, yduJ?, can you give us 
> an idea of why LambdaMOO's so slow.  If it IS my system that's 
> the cause, I'll remove it immediately and until I've fixed it.  
> I don't see why my (alleged) incompetence should be allowed to 
> punish the rest of you.

I never said that you were incompetent. You've done something that's
really quite impressive. I'm guessing at the lag thing; I can't think
of anything -new- that's hit LambdaMOO that would cause the bursts
of horrendous lag... it's an idea that's been bounced around a bit,
and I don't see any reason why it -couldn't- be the new networking
stuff...

> Ok, back to basics, yeah?  There's the network, ok?  I mean 
> the REAL network, not just the toy that I'm playing with, and 
> it's full of useful gadgets that anyone can log into and use.  
> I think it would be neat to be ABLE to mess with those gadgets 
> from LambdaMOO.

Okay, now we get to a question I have which I hope you won't take
as a personal attack.  WHY?  I mean, is LambdaMOO really supposed 
to be our archie server, our irc client, our gateway to other MOOs?
Why not just open another window and run the archie command? shell
out of your tinyfugue session and go into the irc yourself?

I mean, it sounds neat to be able to do these things from LambdaMOO,
but why actually -do- it?

(I'm not even gonna -think- about mentioning theme.)

> Then consider how many MOOs there are in the world, mmmm... seven 
> is it?  Or is it eight?  Fine, now consider how many LPmuds there 
> are in the world.  Let's count them shall we.

o no

> One, two, three, four, five, six, seven, eight, nine, ten, eleven,
> twelve.  Still with me?  Ok, thirteen, fourteen, fifteen, sixteen, 
> seventeen. Mmmm, what's after seventeen, er, eighteen?  Eighteen, 
> nineteen, twenty, twenty one, twenty two...  

That's got a catchy beat, actually.

> Gee there's a lot of LPmuds isn't there?! Wow, just think of all 
> that software on all those sites that we JUST CAN'T USE.

... unless we log into them.

> Just think of all those people on those sites that WE JUST CAN'T 
> TALK TO.

... unless we log in to the site they're on.

> Kinda, makes you wonder doesn't it?

There are oodles of M*s out there.  I don't think they should be 
networked together this way.  I like the way UnterMUD (I think) did
it, where objects actually MOVE from one machine to the next.

> I would value any CONSTRUCTIVE comments you have to offer, but 
> I can't do very much to improve matters if all I get are 
> unspecific opinions.

My SPECIFIC opinion is that this is a terribly impresisve thing that
shouldn't be used. There are enough arguments over what LambdaMOO
should be (theme, non-theme, hacking ground, RPG system...) without
introducing the door to all Internet services.

Honest, I am impressed... I just don't think it's a good idea to keep
it. (Maybe I'm just an old stick-in-the-mud. That might be it, too.)

Seth / Blackbriar @ { LambdaMOO, TinyCWRU, ChaosMOO, MicroMUSE, SludgeMUD }
                                                     (i think)    r.i.p.


From stony-brook.scrc.symbolics.com!yduJ Thu Aug 20 11:34:13 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "10:54:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "21" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 20 Aug 1992 11:34:06 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11570>; Thu, 20 Aug 1992 11:33:31 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11600>; Thu, 20 Aug 1992 11:19:44 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Thu, 20 Aug 1992 11:12:40 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11596>; Thu, 20 Aug 1992 11:12:07 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11594>; Thu, 20 Aug 1992 11:11:29 PDT
Received: from AVOCADO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1127710; 20 Aug 1992 13:49:16-0400
X-NS-Transport-ID: 08002008D0FD00221578
In-Reply-to: <9208201731.AA00620@topaz.cm.cf.ac.uk>
Message-ID: <19920820175419.5.YDUJ@AVOCADO.SCRC.Symbolics.COM>
Date:	Thu, 20 Aug 1992 10:54:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	Andrew.Wilson@computing-maths.cardiff.ac.uk, Moo-Cows.PARC@xerox.com
Subject: Re: Yawn, VROOMs etc.

>  Seriously though, yduJ?, can you give us an idea of
>why LambdaMOO's so slow.

Er, please don't ask me to debug your code.

LambdaMOO is always slow.  If you have a lot of tasks, or you use long
lists, then you are partially to blame.  You can examine your own code
and properties and your own @forked to see if you are causing a problem.

JoeFeedback noticed on ChaosMOO that you're sending a "keepalive" to the
network character every few seconds; perhaps this could be made less
often (like every few minutes, just enough to keep the network
connection open).  Processing failed commands is pretty expensive these
days, and at least on ChaosMOO it was getting a failed command as its
keepalive.  Perhaps you could actually define a verb on your player so
as not to invoke the failed command mechanism.

Now, don't ask me anymore, OK?  If you don't understand what I'm talking
about, think a lot about it or ask someone else.  I think I've been
clear.
						yduJ

From aero.org!obrien Thu Aug 20 13:04:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "12:57:17" "-0700" "Mike O'Brien" "obrien@aero.org" nil "22" "Re: dream hardware/minimal hardware (fwd)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 20 Aug 1992 13:04:51 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11654>; Thu, 20 Aug 1992 13:04:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11653>; Thu, 20 Aug 1992 13:01:46 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 12:59:35 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11619>; Thu, 20 Aug 1992 12:59:04 PDT
Received: from aerospace.aero.org ([130.221.192.10]) by alpha.xerox.com with SMTP id <11653>; Thu, 20 Aug 1992 12:58:03 PDT
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
	id AA07809 for moo-cows.parc@xerox.com; Thu, 20 Aug 1992 12:57:28 -0700
Posted-Date: Thu, 20 Aug 92 12:57:17 PDT
Received: from tobler.aero.org by antares.aero.org (4.1/AMS-1.0)
	id AA11280 for pavel@parc.xerox.com; Thu, 20 Aug 92 12:57:26 PDT
X-NS-Transport-ID: 08002008D0FD002217E8
In-Reply-to: "Your message of \"Tue, 18 Aug 92 11:41:51 -0900.\"
             <92Aug18.114155pdt.58372@lambda.parc.xerox.com>5"
Message-ID: <199208201957.AA07809@aerospace.aero.org>
Date:	Thu, 20 Aug 1992 12:57:17 -0700
From:	Mike O'Brien <obrien@aero.org>
To:	Pavel Curtis <Pavel@parc.xerox.com>
cc:	moo-cows.parc@xerox.com
Subject: Re: dream hardware/minimal hardware (fwd)

>Yes, well, you'd like that, but Sun Microsystems (apparently among others) in
>its infinite wisdom decided not to implement copy-on-write virtual memory
>sharing.  Thus, in order to do the fork, the system does indeed copy the entire
>image of the forking process and thus doubles the swap space and physical
>memory demand.
>
>Sigh.

Yah, as an ex-member of the DARPA Steering Committee that oversaw the development
of Berkeley UNIX, I can tell you we've only been waiting ten years for this
to go in.  It was originally a bug in the VAX 750 microcode that prevented this
from happening; not exactly a relevant excuse now.

However...

My impression was that the only reason you fork to write the database is to
ensure a consistent database while not locking out interactions.  With the
amount of page-thrashing caused by the fork of a large MOO, might it not be
a better idea to lock out the interactions, and update the database without
forking?  Overall response time MIGHT be improved by this!

Mike O'Brien

From parc.xerox.com!masinter Thu Aug 20 13:43:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "13:28:34" "-0700" "Larry Masinter" "masinter@parc.xerox.com" nil "13" "Re: Yawn, VROOMs etc." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 20 Aug 1992 13:43:33 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11665>; Thu, 20 Aug 1992 13:42:31 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11656>; Thu, 20 Aug 1992 13:40:11 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Thu, 20 Aug 1992 13:36:06 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11635>; Thu, 20 Aug 1992 13:35:46 PDT
Received: from poplar.parc.xerox.com ([13.2.16.165]) by alpha.xerox.com with SMTP id <11635>; Thu, 20 Aug 1992 13:28:56 PDT
Received: by poplar.parc.xerox.com id <101795>; Thu, 20 Aug 1992 13:28:46 -0700
Fake-Sender: masinter@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00221875
In-Reply-to: "seth%CAMP@onet.edu's message of Thu, 20 Aug 1992 12:48:52 -0700 <92Aug20.124915pdt.101808@poplar.parc.xerox.com>"
Message-ID: <92Aug20.132846pdt.101795@poplar.parc.xerox.com>
Date:	Thu, 20 Aug 1992 13:28:34 -0700
From:	Larry Masinter <masinter@parc.xerox.com>
To:	seth%CAMP@onet.edu
cc:	moo-cows.parc@xerox.com
Subject: Re: Yawn, VROOMs etc.

I think 'access to internet services' is a good 'theme' for AstroMOO,
where the theme is 'giving astronomers access to data across the
internet'. It isn't as good a theme for LambdaMOO, but heck, that's
not what this list is about.

These days, I'd like a moo/world-wide-web gateway to play with.
(Telnet to info.cern.ch).

Larry
(Grump@LambdaMOO)




From parc.xerox.com!pavel Thu Aug 20 13:49:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "13:38:20" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "15" "Re: dream hardware/minimal hardware (fwd)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 20 Aug 1992 13:49:52 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11661>; Thu, 20 Aug 1992 13:49:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11641>; Thu, 20 Aug 1992 13:47:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Thu, 20 Aug 1992 13:43:50 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11657>; Thu, 20 Aug 1992 13:42:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11654>; Thu, 20 Aug 1992 13:40:28 PDT
Received: by lambda.parc.xerox.com id <58374>; Thu, 20 Aug 1992 13:40:19 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002218C1
In-Reply-to: <199208201957.AA07809@aerospace.aero.org>
Message-ID: <92Aug20.134019pdt.58374@lambda.parc.xerox.com>
References: <199208201957.AA07809@aerospace.aero.org>
	<92Aug18.114155pdt.58372@lambda.parc.xerox.com>
Date:	Thu, 20 Aug 1992 13:38:20 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	obrien@aero.org
cc:	moo-cows.parc@xerox.com
Subject: Re: dream hardware/minimal hardware (fwd)

> Date:	Thu, 20 Aug 1992 12:57:17 -0700
> From:	Mike O'Brien <obrien@aero.org>

> My impression was that the only reason you fork to write the database is to
> ensure a consistent database while not locking out interactions.  With the
> amount of page-thrashing caused by the fork of a large MOO, might it not be
> a better idea to lock out the interactions, and update the database without
> forking?  Overall response time MIGHT be improved by this!

I think that it would be worse than the current situation for the MOO to be
*completely* unresponsive during the time it was checkpointing.  In any case,
the point will soon be moot, as of the end-of-September release that uses a
fully disk-based DB.

	Pavel

From suna0.cs.uiuc.edu!scott Thu Aug 20 15:54:55 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "15:48:17" "-0700" "Jay Scott" "scott@suna0.cs.uiuc.edu" nil "15" "Re: built-in parser" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 20 Aug 1992 15:54:54 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11690>; Thu, 20 Aug 1992 15:54:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11693>; Thu, 20 Aug 1992 15:52:47 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Thu, 20 Aug 1992 15:48:04 -0700
Received: from sparc7.cs.uiuc.edu ([128.174.244.117]) by alpha.xerox.com with SMTP id <11684>; Thu, 20 Aug 1992 15:47:33 PDT
Received: by sparc7.cs.uiuc.edu id AA20903
  (5.65c/IDA-1.4.4 for moo-cows@parc.xerox.com); Thu, 20 Aug 1992 17:48:17 -0500
X-NS-Transport-ID: 08002008D0FD00221AE3
Message-ID: <199208202248.AA20903@sparc7.cs.uiuc.edu>
Date:	Thu, 20 Aug 1992 15:48:17 -0700
From:	Jay Scott <scott@suna0.cs.uiuc.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: built-in parser

>From pavel@parc.xerox.com Thu Aug 20 12:14:28 1992
>
>> Date:	Wed, 19 Aug 1992 21:23:04 -0700
>> From:	Jay Scott <scott@suna0.cs.uiuc.edu>
>> 
>> Is it easy to hack the server to turn off its built-in parser?
>...
>It would be easy to add a compile-time option that would send all user commands
>to some particular verb, such as #0:do_command(commandstr); is that what you
>want?

Yes, that would be good.

	Frand
	scott@cs.uiuc.edu

From computing-maths.cardiff.ac.uk!Andrew.Wilson Thu Aug 20 17:45:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "20" "August" "1992" "17:34:56" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "16" "Re: Why's the MOO so slow (not entirely serious?)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 20 Aug 1992 17:44:52 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11908>; Thu, 20 Aug 1992 17:43:53 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11846>; Thu, 20 Aug 1992 17:41:54 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Thu, 20 Aug 1992 17:37:00 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11706>; Thu, 20 Aug 1992 17:36:31 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11705>; Thu, 20 Aug 1992 17:35:37 PDT
Via: uk.ac.cardiff.computing-maths; Fri, 21 Aug 1992 01:35:10 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <29807-0@sentinel.cm.cf.ac.uk>; Fri, 21 Aug 1992 01:35:03 +0100
X-NS-Transport-ID: 08002008D0FD00221C29
Message-ID: <9208210034.AA00993@topaz.cm.cf.ac.uk>
Date:	Thu, 20 Aug 1992 17:34:56 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	Moo-Cows.PARC@xerox.com
Subject: Re: Why's the MOO so slow (not entirely serious?)



Hi,

	Oh, no!  My MOO's overloaded with other people's stupid
programs.  Heck, why can't they just do all their expensive calulations
on another machine, just get the results, and leave all the rest of the
CPU time to people who really need it!  Mmm, that's a thought, how'd they do
that?  I guess they'd need some way of transferring data to and from other MOOs
and some way of telling the other MOOs what to do with the data once they'd got
it.  Now what's the best way of doing that do you suppose?  Mmmm, nope, you got
me again.  I can't figure that one out.  Pity though, eh?  It'd be kinda
nice to have something like that if you ever needed it.

Networker @ Leading edge of MOOnology.


From casbah.acns.nwu.edu!hpa Fri Aug 21 08:26:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "21" "August" "1992" "08:14:49" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "26" "open_network_connection()" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 21 Aug 1992 08:26:12 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11777>; Fri, 21 Aug 1992 08:25:11 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11747>; Fri, 21 Aug 1992 08:20:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 21 Aug 1992 08:15:55 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11756>; Fri, 21 Aug 1992 08:15:33 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA02860; Fri, 21 Aug 92 10:14:57 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002224AD
Message-ID: <9208211514.AA02860@casbah.acns.nwu.edu>
Date:	Fri, 21 Aug 1992 08:14:49 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: open_network_connection()
Reply-to: hpa@nwu.edu

I am sorry, first of all, to add this to the universal wish list for the
MOO server when I know how much work it takes to do the server... I am just
worried that if I make a patch it will be obsolete by the time I finish it!

Anyway, would it be possible to add a flag to the MOO side of the
networking interface so that input received from connections created by
open_network_connection() would be queued rather than fed to the builtin
parser if no read() was pending?  I run into the problem while trying to
make a MOO implementation of SMTP that the first line of input (221 service
ready) comes so quickly after the network connection has been opened that
no matter how I do it, I cannot get the MOO to be in read() mode by the
time the line arrives.

Furthermore, such queuing would eliminate (or at least reduce) the problem
about phase errors in action/reply protocols such as SMTP.  It would be
possible to let one task take care of both input and output.

Comments?

	/hpa * Xorbon * Zytor

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
"That dreemless sleep that cures all aches."

From parc.xerox.com!pavel Fri Aug 21 10:37:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "21" "August" "1992" "10:30:27" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "45" "Re: open_network_connection()" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Fri, 21 Aug 1992 10:37:30 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11756>; Fri, 21 Aug 1992 10:36:40 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11759>; Fri, 21 Aug 1992 10:34:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Fri, 21 Aug 1992 10:31:08 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11783>; Fri, 21 Aug 1992 10:30:44 PDT
Received: by lambda.parc.xerox.com id <58378>; Fri, 21 Aug 1992 10:30:34 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00222729
In-Reply-to: <9208211514.AA02860@casbah.acns.nwu.edu>
Message-ID: <92Aug21.103034pdt.58378@lambda.parc.xerox.com>
References: <9208211514.AA02860@casbah.acns.nwu.edu>
Date:	Fri, 21 Aug 1992 10:30:27 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	hpa@nwu.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: open_network_connection()

> Date:	Fri, 21 Aug 1992 08:14:49 -0700
> From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)

> ...

> Anyway, would it be possible to add a flag to the MOO side of the
> networking interface so that input received from connections created by
> open_network_connection() would be queued rather than fed to the builtin
> parser if no read() was pending?  I run into the problem while trying to
> make a MOO implementation of SMTP that the first line of input (221 service
> ready) comes so quickly after the network connection has been opened that
> no matter how I do it, I cannot get the MOO to be in read() mode by the
> time the line arrives.
> 
> Furthermore, such queuing would eliminate (or at least reduce) the problem
> about phase errors in action/reply protocols such as SMTP.  It would be
> possible to let one task take care of both input and output.

First, let me be the first to admit that the current system of treating
outbound network connections as if they were inbound ones was clearly a crock;
I did it in an evening because someone really wanted some way of making
outbound network connections and this way was easy and cute (in a fairly
grotesque sort of way... :-).

Anyhow, the only way to avoid losing in the current system is that the *very
same task* that calls open_network_connection() *must* be the one that calls
read() and that task *must always* be the one that calls read() and that task
*must not* ever suspend except by calling read() on that connection, all until
the connection is finally closed by someone calling boot_player().

If you follow this rule, then the atomicity of MOO tasks guarantees that there
will never be an opportunity for the server to misinterpret input on the
connection as a command.

Now, I have already been thinking recently about how to rearrange the
modularity of the server to make it relatively `clean' to have the task queues
for outbound connections get marked as, if you will, `read()-only'; this would
eliminate current crockery of it all, including the nasty bit about how the
connection can `time out' and be closed by the server if it remains idle for
more than five minutes... :-(

I may well do something about all this for the next release, along with all of
the other networking changes.

	Pavel/Haakon

From parc.xerox.com!pavel Fri Aug 21 14:08:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "21" "August" "1992" "14:00:25" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "29" "System V test case" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 21 Aug 1992 14:08:49 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11810>; Fri, 21 Aug 1992 14:07:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11798>; Fri, 21 Aug 1992 14:04:35 PDT
Received: by lambda.parc.xerox.com id <58379>; Fri, 21 Aug 1992 14:00:37 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00222A9B
Message-ID: <92Aug21.140037pdt.58379@lambda.parc.xerox.com>
Date:	Fri, 21 Aug 1992 14:00:25 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: System V test case

Folks, I need some help in order to do a good job of the multi-network release
of the server.

I you have access to a machine that claims to run UNIX System V Release 3.0 or
later (especially if that machine does not implement Berkeley-style networking
primitives; type `man socket' to see if it does), then I'd like you to compile
and run the enclosed program and send me the results.

To do this, copy the program into /tmp/foo.c and cd to /tmp.  Then type

	cc -o foo foo.c

The program should compile just fine, without any errors or warnings from the
compiler at all.  If this is not the case, please send me its output.

Assuming that it compiled, please type

	date; ./foo; date

This should produce exactly three lines of output: two dates and a line in
between from the program.  Please send me all of that output, including the two
dates.

When you send me these results, please include a description of the kind of
hardware and operating system you used.

Thanks very much,

	Pavel/Haakon

From parc.xerox.com!pavel Fri Aug 21 14:11:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "21" "August" "1992" "14:01:29" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "62" "Oops!  Here's the test case..." "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 21 Aug 1992 14:11:21 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11816>; Fri, 21 Aug 1992 14:09:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11808>; Fri, 21 Aug 1992 14:07:45 PDT
Received: by lambda.parc.xerox.com id <58380>; Fri, 21 Aug 1992 14:04:43 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00222AB4
Message-ID: <92Aug21.140443pdt.58380@lambda.parc.xerox.com>
Date:	Fri, 21 Aug 1992 14:01:29 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Oops!  Here's the test case...

I forgot to enclose the System V test program.  Here it is.

	Pavel/Haakon

--- Begin foo.c ---
#include <sys/types.h>
#include <poll.h>
#include <sys/stat.h>
#include <fcntl.h>

main()
{
    int	rfd, wfd, i;
    struct pollfd fds[1];

    unlink("/tmp/pavel");
    if (mknod("/tmp/pavel", 0666 | S_IFIFO, 0) < 0) {
	perror("Making the FIFO");
	exit(-1);
    } else if ((rfd = open("/tmp/pavel", O_RDONLY | O_NDELAY)) < 0) {
	perror("Opening the FIFO for reading");
	exit(-1);
    } else if ((wfd = open("/tmp/pavel", O_WRONLY)) < 0) {
	perror("Opening the FIFO for writing");
	exit(-1);
    }

    if (fork() == 0) {
	close(rfd);
	sleep(2);
	exit(0);
    }

    close(wfd);

    fds[0].fd = rfd;
    fds[0].events = POLLIN;

    if ((i = poll(fds, 1, 10000)) < 0) {
	perror("Polling");
	exit(-1);
    }

    printf("Polling succeeded with result %d and flags:", i);
    if (fds[0].revents & POLLIN)
	printf(" POLLIN");
    if (fds[0].revents & POLLOUT)
	printf(" POLLOUT");
    if (fds[0].revents & POLLPRI)
	printf(" POLLPRI");
    if (fds[0].revents & POLLERR)
	printf(" POLLERR");
    if (fds[0].revents & POLLHUP)
	printf(" POLLHUP");
    if (fds[0].revents & POLLNVAL)
	printf(" POLLNVAL");

    printf("\n");

    exit(0);
}
--- End foo.c ---

From netcom.com!frankc Fri Aug 21 17:41:17 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "21" "August" "1992" "17:34:18" "-0700" "Frank Crowell" "frankc@netcom.com " nil "28" "Guest Logins" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Fri, 21 Aug 1992 17:41:10 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11952>; Fri, 21 Aug 1992 17:40:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11969>; Fri, 21 Aug 1992 17:38:53 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58381>; Fri, 21 Aug 1992 17:35:49 -0700
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11913>; Fri, 21 Aug 1992 17:35:23 PDT
Received: by netcom.netcom.com (4.1/SMI-4.1)
	id AA01738; Fri, 21 Aug 92 17:34:20 PDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00222DC0
Message-ID: <9208220034.AA01738@netcom.netcom.com>
Date:	Fri, 21 Aug 1992 17:34:18 -0700
From:	frankc@netcom.com (Frank Crowell)
To:	moo-cows@parc.xerox.com
Subject: Guest Logins

"Why Vrooms?".  Well reading some postings in the LPmud
newsgroup about one-shot character creations, another use of VRoom 
would be to eliminate some of the silly
character creations that are done on some muds just so that
someone can talk to another person on mud.
[yes, i know that the players can come in as guest, except:
	1. only one guest is allowed on most systems
	2. the people don't use guest, they create a character
and if you don't fully understand why people do #2, read #1 again for one
reason why; there are other reason also]

But then a more general question also occurs to me: why not
have visitor status characters. Basically, a visitor character
can exist for the duration of that one session, then is purged.

Too silly? Well consider this. I want to invite 500 of my closest
LPmud friends over for an evening at my favorite MOO.
Hm.  SillyPerson say "Guest237, would you like more root beer?"

Maybe "visitor" could mean "named, invited guest", if security was
an issue. Pleez no badges!

Comments? ImplementationNotes?
[Wait, 'implementation' is too long and formal--> BuilderNotes?]

-- 
Frank Crowell frankc@netcom.COM
[This Space for Rent]

From stony-brook.scrc.symbolics.com!yduJ Fri Aug 21 20:17:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "21" "August" "1992" "20:14:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "13" "Guest Logins" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 21 Aug 1992 20:17:34 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12047>; Fri, 21 Aug 1992 20:15:47 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12048>; Fri, 21 Aug 1992 20:14:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58382>; Fri, 21 Aug 1992 20:11:13 -0700
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12047>; Fri, 21 Aug 1992 20:10:42 PDT
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1128825; 21 Aug 1992 23:11:41-0400
X-NS-Transport-ID: 08002008D0FD00222EDC
In-Reply-to: <9208220034.AA01738@netcom.netcom.com>
Message-ID: <19920822031442.1.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Fri, 21 Aug 1992 20:14:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	frankc@netcom.com, moo-cows@parc.xerox.com
Subject: Guest Logins

On some muds, guests are allowed to temporarily name and describe
themselves.  This has been proposed on LambdaMOO; we have allowed guests
to describe themselves though not yet to name themselves.

LambdaMOO has ten guest characters, and the LambdaCore provides the code
for having many guests, just create more children of $guest.  I have
never seen more than four or so guests in use at a random time, though
we sometimes have lots of guests when someone gives a talk about MOO and
invites everyone to be a Guest on Lambda.  I think the only times we've
actually run out of guests have been when some idiot has decided to try
finding out just what happens when they personally login all 10 guests.
(They get turned into a newt, if we catch them :-)
							yduJ

From computing-maths.cardiff.ac.uk!Andrew.Wilson Mon Aug 24 06:13:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "06:00:05" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "26" "Is ChaosMOO a 'standard' MOO?" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 06:12:56 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11568>; Mon, 24 Aug 1992 06:11:47 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11572>; Mon, 24 Aug 1992 06:08:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 24 Aug 1992 06:02:15 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11562>; Mon, 24 Aug 1992 06:01:46 PDT
Via: uk.ac.cardiff.computing-maths; Mon, 24 Aug 1992 14:00:52 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <17323-0@sentinel.cm.cf.ac.uk>; Mon, 24 Aug 1992 14:00:27 +0100
X-NS-Transport-ID: 08002008D0FD00223E0D
Message-ID: <9208241300.AA01775@turquoise.cm.cf.ac.uk>
Date:	Mon, 24 Aug 1992 06:00:05 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com
Subject: Is ChaosMOO a 'standard' MOO?


THIS IS NOT A REQUEST FOR HELP IN DEBUGGING MY CODE :-)

Hi,
	it's no big deal, but I noticed something strange happening
when I link MOO-net to ChaosMOO.  ChaosMOO automatically logs a character into
my site!  DreaMOO doesn't do this, neither does LambdaMOO.

Wizards might like to check this.  Fix up a test moo which allows any
character to be created:

	moo LambdaCore-6Aug92.db TRASH

Log yourself in as wizard and then do:

	;open_network_connection("ChaosMOO's IP number", ChaosMOO's Port)

(don't ask!).

And see if "player" comes to visit you.

Is there anyone at ChaosMOO who could save me the brain-ache and let me know
what I'm not doing wrong?

Netpest @ InYourHairAgainMOO


From computing-maths.cardiff.ac.uk!Andrew.Wilson Mon Aug 24 07:07:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "06:56:57" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "64" "Re: Guest Logins" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 07:07:39 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11544>; Mon, 24 Aug 1992 07:06:29 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11569>; Mon, 24 Aug 1992 07:04:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Mon, 24 Aug 1992 06:58:06 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11544>; Mon, 24 Aug 1992 06:57:46 PDT
Via: uk.ac.cardiff.computing-maths; Mon, 24 Aug 1992 14:57:05 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <18905-0@sentinel.cm.cf.ac.uk>; Mon, 24 Aug 1992 14:57:02 +0100
X-NS-Transport-ID: 08002008D0FD00223EAA
Message-ID: <9208241356.AA01813@turquoise.cm.cf.ac.uk>
Date:	Mon, 24 Aug 1992 06:56:57 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com
Subject: Re: Guest Logins


 

Hi,
	Frank Crowell (frankc@netcom.com) said:

>"Why Vrooms?".  Well reading some postings in the LPmud
>newsgroup about one-shot character creations, another use of VRoom 
>would be to eliminate some of the silly
>character creations that are done on some muds just so that
>someone can talk to another person on mud.

This IS certainly a legitimate (read, Wow! so they are useful after all!)
use for VROOMs.  Characters wishing to visit our MOO would actually be logged
into another MOO and would communicate with our MOO using a VROOM.  This
is fine, but the characters would STILL need an account on the other MOO
to be able to do this.  Visiting characters would probably wany to use
objects defined on the site they're visiting, and (wonderful though they are)
VROOMs still can't let characters use objects defined on a another MOO.

The principal advantage of VROOMs, really an implication of the way that
MOO-net's network connenctions are implemented, is that no matter how many
visitors there are in a VROOM, they are linked to our MOO through only ONE login
per connected site.

For example:

	A couple of days ago, I (Networker @ CardiffMOO) was talking to
six other MOO characters using a VROOM.  Four of the characters were on
LambdaMOO and the other two were on DreaMOO.  Using the 'conventional' 
login technique this would mean that there would need to be seven characters
logged into CardiffMOO at the same time.  This situation might not be desirable
nor even possible, and both conditions were true for CardiffMOO at the time:
Firstly, CardiffMOO's host is a small Sun WorkStation, and is VERY slow with
seven incoming connections.  Secondly Cardiff University, the domain that
the workstation exists in, is firewalled.  No external logins are permitted,
so even if you DID know CardiffMOO's IP address and port number you STILL
couldn't get in.

Using the current implementation of MOO-net, the characters were able to 'visit'
CardiffMOO though only two network connections.  The connections from CardiffMOO
to LambdaMOO and DreaMOO were initiated by CardiffMOO using calls to the
open_network_connection() built-in.  Simply put, CardiffMOO had seven characters
interacting using only 3 telnet-like login connections.

>But then a more general question also occurs to me: why not
>have visitor status characters. Basically, a visitor character
>can exist for the duration of that one session, then is purged.
>Too silly? Well consider this. I want to invite 500 of my closest
>LPmud friends over for an evening at my favorite MOO.
>Hm.  SillyPerson say "Guest237, would you like more root beer?"


I think that 'one shot' characters ARE a good idea.  A visitor SHOULD
be nameable and describable and this is an idea that should be implemented
in the next LambdaCore.  It's worth pointing out however that visitors
alone would not be enough to enable '500 of my closest LPmud friends over for an evening at my favorite MOO'.  Can you imagine 500 people all logged into
LambdaMOO at the same time.  Did someone say lag?


Networker @ JustLetMeKnowIfYou'reGettingTiredOfThisNonsenseMOO

ps.	On a more personal note, can anyone tell me why I write so much when
	I have so little to say?

From casbah.acns.nwu.edu!hpa Mon Aug 24 15:20:45 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "15:11:24" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "14" "Bug in read()" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 24 Aug 1992 15:20:42 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11678>; Mon, 24 Aug 1992 15:19:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11608>; Mon, 24 Aug 1992 15:17:08 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 24 Aug 1992 15:11:55 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11701>; Mon, 24 Aug 1992 15:11:29 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA06639; Mon, 24 Aug 92 17:11:25 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0022475B
Message-ID: <9208242211.AA06639@casbah.acns.nwu.edu>
Date:	Mon, 24 Aug 1992 15:11:24 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: Bug in read()
Reply-to: hpa@nwu.edu

There seems to be a bug in read() with the following sympthom:

If the player connection subjected to read() disconnects while read() is
active, the reading task locks up instead of returning an error message.  I
got my SMTP client working, except that it never returns, and cannot
process status output for the reason.

	/hpa

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
Have you kissed your Swede today?

From computing-maths.cardiff.ac.uk!Andrew.Wilson Mon Aug 24 16:07:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "15:55:18" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "56" "Re: Bug in read()" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 16:07:50 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11664>; Mon, 24 Aug 1992 16:06:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11653>; Mon, 24 Aug 1992 16:04:33 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Mon, 24 Aug 1992 16:00:02 -0700
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11661>; Mon, 24 Aug 1992 15:59:30 PDT
Via: uk.ac.cardiff.computing-maths; Mon, 24 Aug 1992 23:55:34 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <02034-0@sentinel.cm.cf.ac.uk>; Mon, 24 Aug 1992 23:55:27 +0100
X-NS-Transport-ID: 08002008D0FD0022483C
Message-ID: <9208242255.AA02126@turquoise.cm.cf.ac.uk>
Date:	Mon, 24 Aug 1992 15:55:18 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows@parc.xerox.com, hpa@nwu.edu
Subject: Re: Bug in read()


Hi,

	low, middling, (alcohol, in case you're interested),

H. Peter Anvin (hpa@casbah.acns.nwu.edu) says:

>There seems to be a bug in read() with the following sympthom: [sic]

>If the player connection subjected to read() disconnects while read() is
>active, the reading task locks up instead of returning an error message.  I
>got my SMTP client working, except that it never returns, and cannot
>process status output for the reason.

I assume you mean 'player' in terms of a player who's actually logged in.

Alternatively, if a verb of yours does:

	connection = open_network_connection(<whatever>);
	fork (0)
		while (1)
			line = read(connection);
		endwhile;
	endfork;

and if, at some later time, you type:

	;boot_player(x);

the error IS caught.  If your verb is in debug mode then you get a trace-back
indicating the line with the read(connection) statement on it.  The same error
is caught if the site you're connecting to does a ;boot_player().

This information is offered, not as a solution to Peter's problem but as
an indication of read()'s behaviour under other 'extreme' conditions.
I think it would be helpful to the MOO community if there was an official
statement about the semantics of open_network_connection(), read() and
other 'low-level' functions in the event of a break in the connection involved.
I realise that o_n_c() is undergoing some degree of review at the the moment,
however, would anyone in the know care to comment further, the manuals are
not as helpful as they could be.

Thanks,
	Andy.  (Net<whatever> @ <Forget it.  It's been a long night and if I
		start worrying about trivial matters now I'm NEVER gonna
		make it!>)

ps.	I'm running server version 1.6.1, LambdaCore-6Aug92.db with only my
	MOO-net code in addition.

pps.	The way Ripley died.  That was SOOO moving.  I think I'm going to
	cry all night.





From casbah.acns.nwu.edu!hpa Mon Aug 24 16:32:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "16:24:05" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " nil "62" "Re: Bug in read()" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 16:32:37 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11667>; Mon, 24 Aug 1992 16:31:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11671>; Mon, 24 Aug 1992 16:29:36 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Mon, 24 Aug 1992 16:24:48 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11661>; Mon, 24 Aug 1992 16:24:14 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA10618; Mon, 24 Aug 92 18:24:07 CDT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0022489A
In-Reply-to: "<9208242255.AA02126@turquoise.cm.cf.ac.uk>; from \"Andrew Wilson\" at Aug 24, 92 11:55 pm"
Message-ID: <9208242324.AA10618@casbah.acns.nwu.edu>
Date:	Mon, 24 Aug 1992 16:24:05 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	Andrew.Wilson@computing-maths.cardiff.ac.uk (Andrew Wilson)
cc:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: Re: Bug in read()
Reply-to: hpa@nwu.edu

You write:
> 
> >There seems to be a bug in read() with the following sympthom: [sic]
> 
> >If the player connection subjected to read() disconnects while read() is
> >active, the reading task locks up instead of returning an error message.  I
> >got my SMTP client working, except that it never returns, and cannot
> >process status output for the reason.
> 
> I assume you mean 'player' in terms of a player who's actually logged in.
> 
> Alternatively, if a verb of yours does:
> 
> 	connection = open_network_connection(<whatever>);
> 	fork (0)
> 		while (1)
> 			line = read(connection);
> 		endwhile;
> 	endfork;
> 
> and if, at some later time, you type:
> 
> 	;boot_player(x);
> 
> the error IS caught.  If your verb is in debug mode then you get a trace-back
> indicating the line with the read(connection) statement on it.  The same error
> is caught if the site you're connecting to does a ;boot_player().
> 

In one of my verbs I had this loop

this.io = {};
this.active = 1;

conn = open_network_connection(<stuff>);

fork(0)
   <Stuff that among other things reads from this.io>
   boot_player(conn);
endfork

while ( typeof(rl = read(conn)) == STR )
   this.io = { @this.io, rl };
endwhile

this.io = { @this.io, "999 Connection closed" };
this.active = 0;


... well, the connection opened and closed, but the while() loop never fell
thought, which it ought to have done since read() should have returned an
error.  My experiments *seem* to indicate that the problems occur when the
other side closes the connection before the boot_player() is reached, but
I am not 100% certain.

	/hpa

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
"Kissing a smoker is like licking an ashtray."  -- R. Heinlein

From minos.nmt.edu!schlake Mon Aug 24 18:42:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "18:29:48" "-0700" "Schlake" "schlake@minos.nmt.edu " nil "15" "NON-MOO stuff" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 18:41:59 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11709>; Mon, 24 Aug 1992 18:41:34 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11711>; Mon, 24 Aug 1992 18:39:40 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Mon, 24 Aug 1992 18:33:46 -0700
Received: from minos.nmt.edu ([129.138.1.5]) by alpha.xerox.com with SMTP id <11705>; Mon, 24 Aug 1992 18:33:20 PDT
Received: by minos.nmt.edu
	(16.6/15.6) id AA24105; Mon, 24 Aug 92 19:29:49 -0600
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
X-NS-Transport-ID: 08002008D0FD00224A36
Message-ID: <9208250129.AA24105@minos.nmt.edu>
Date:	Mon, 24 Aug 1992 18:29:48 -0700
From:	schlake@minos.nmt.edu (Schlake)
To:	moo-cows@parc.xerox.com
Subject: NON-MOO stuff

This is non MOO stuff.  First and foremost, I need to request removal from
the list because I'm about to tour the country on my mountain bike.  I
know it is bad form to ask that here, but I have other things to say.  :)

Second, I'm willingly to go out of my way to meet anyone who wants too.  I
haven't met many mudders, and it is about time I did.  :)  I haven't been
on Lambda much since me and Yduj had a few tense moments, but I do still
like MOO, and I miss the few people I knew there.  Just email me a name,
address, and phone if you want me to try and visit you.

Oh, please, no responses to this on moo-cows, just send them to me.  Flame
as you like, I don't care.  :)


-- void *(*(*schlake())[])(void *);

From senex.unh.edu!unhtel!morwyn!root Mon Aug 24 23:12:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "23:01:43" "-0700" "Forrie Aldrich" "root@morwyn.uucp" nil "14" "MUSH/MUD --> MOO ?" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 23:12:11 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11725>; Mon, 24 Aug 1992 23:10:19 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11723>; Mon, 24 Aug 1992 23:08:51 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Mon, 24 Aug 1992 23:04:20 -0700
Received: from senex.unh.edu ([132.177.128.103]) by alpha.xerox.com with SMTP id <11717>; Mon, 24 Aug 1992 23:03:57 PDT
Received: by senex.unh.edu id AA08893
  (5.65c+/IDA-1.4.4 for parc.xerox.com!Moo-Cows); Tue, 25 Aug 1992 02:06:41 -0400
Received: by unhtel.unh.edu (smail2.5R)
	id AA16028; 25 Aug 92 02:07:16 EDT (Tue)
Received: by morwyn.UUCP id AA10901
  (5.65c/IDA-1.4.4 for Moo-Cows@parc.xerox.com); Tue, 25 Aug 1992 02:01:43 -0400
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
X-NS-Transport-ID: 08002008D0FD00224C7B
Message-ID: <199208250601.AA10901@morwyn.UUCP>
Date:	Mon, 24 Aug 1992 23:01:43 -0700
From:	Forrie Aldrich <root@morwyn.uucp>
Sender: unhtel!morwyn!root@senex.unh.edu
To:	Moo-Cows@parc.xerox.com
Subject: MUSH/MUD --> MOO ?

Just out of curiousity (or lack of knowledge), is there a way to take a
MUD/MUSH database/mudlib (or whatever they call it these days) and
convert it systematically into a MOO database...?  I can imagine that
such a task would be highly meticulous (if it's possible at all), but
wondered if there was a 'way' to accomplish such a task.

Many thanks...

-- 
	   -----------	      Forrest Aldrich	      -----------
	   -------     morwyn!forrie@unhtel.unh.edu	  -------
	   ----						     ----
	   --	     VISION GRAPHICS --	Dover, NH - USA	       --
	   ------------------------------------------------------

From nexus.yorku.ca!s442223 Mon Aug 31 00:29:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "29" "August" "1992" "09:20:20" "-0700" "s442223@nexus.yorku.ca" "s442223@nexus.yorku.ca" nil "5" "ChaosMOO has been moved!" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 31 Aug 1992 00:29:38 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11537>; Mon, 31 Aug 1992 00:28:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11532>; Mon, 31 Aug 1992 00:18:34 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 31 Aug 1992 00:14:49 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11522>; Mon, 31 Aug 1992 00:14:28 PDT
Received: from nexus.yorku.ca ([130.63.9.66]) by alpha.xerox.com with SMTP id <11903>; Sat, 29 Aug 1992 09:20:44 PDT
Received: by nexus.yorku.ca id <9226>; Sat, 29 Aug 1992 12:20:34 -0400
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
X-NS-Transport-ID: 08002008D0FD00234C56
Message-ID: <92Aug29.122034edt.9226@nexus.yorku.ca>
Date:	Sat, 29 Aug 1992 09:20:20 -0700
From:	s442223@nexus.yorku.ca
To:	MOO-Cows.PARC@xerox.com
Subject: ChaosMOO has been moved!

ChaosMOO's new address is cub.math.oxy.edu 7777.
Thanks.

-- 
Chaos is s442223@nexus.yorku.ca

From cheetah.math.oxy.edu!t_pascal Mon Aug 31 00:33:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "29" "August" "1992" "10:23:58" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "3" "ChaosMOO has moved!" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 31 Aug 1992 00:33:23 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11522>; Mon, 31 Aug 1992 00:32:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11536>; Mon, 31 Aug 1992 00:26:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 31 Aug 1992 00:23:15 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11537>; Mon, 31 Aug 1992 00:18:50 PDT
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <11994>; Sat, 29 Aug 1992 10:34:17 PDT
Received: from cub.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA02132; Sat, 29 Aug 92 10:24:00 PDT
Received: by cub.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05647; Sat, 29 Aug 92 10:23:58 GMT-0700
X-NS-Transport-ID: 08002008D0FD00234C8B
Message-ID: <9208291724.AA02132@cheetah.math.oxy.edu>
Date:	Sat, 29 Aug 1992 10:23:58 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	MOO-Cows.PARC@xerox.com
Subject: ChaosMOO has moved!


ChaosMOO has been moved to cub.math.oxy.edu 7777!
Please take note of this.

From cheshire.oxy.edu!t_pascal Mon Aug 31 11:57:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "29" "August" "1992" "13:22:12" "-0700" "C. Regis Wilson" "t_pascal@cheshire.oxy.edu " nil "24" "Chas moo moves to a new channel" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Mon, 31 Aug 1992 11:57:05 -0700
Received: from Nuncio.Parc.Xerox.xns by alpha.xerox.com via XNS id <11545>; Mon, 31 Aug 1992 11:55:11 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11566>; Mon, 31 Aug 1992 11:49:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 31 Aug 1992 11:46:48 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11537>; Mon, 31 Aug 1992 11:46:27 PDT
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <12153>; Sat, 29 Aug 1992 13:22:15 PDT
Received: from cheshire.oxy.edu by gate.oxy.edu (4.0/SMI-4.0)
	id AA14823; Sat, 29 Aug 92 13:22:29 PDT
Received: by cheshire.oxy.edu (4.1/SMI-4.1)
	id AA15464; Sat, 29 Aug 92 13:22:12 PDT
X-NS-Transport-ID: 08002008D0FD002B8D41
Message-ID: <9208292022.AA15464@cheshire.oxy.edu>
Date:	Sat, 29 Aug 1992 13:22:12 -0700
From:	t_pascal@cheshire.oxy.edu (C. Regis Wilson)
To:	moo-cows.PARC@xerox.com
Subject: Chas moo moves to a new channel


The chaos moo, workshop for degenerate and small programmers
(no offense, I'm one too!) has moved from it's previous haven

jaguar.math.oxy.edu 8888

To:

cub.math.oxy.edu 8888

It's a slower machine, but the memory is more loose, so the
memory panics should go away.   Mark it down on your calendars
and enjoy!  (Not for the weak of heart)

[Disclaimer:  This product may warrent your void and also causes
gas in untrained lavatory toddlers.  Use only as directemented,
only as C scribed.]

---------
T. Pascal, King of Pascal    |  "The man on the moon told us he subsisted by
1600 Campus Road, Box 829    |   digging up cheese from his back yard.
Los Angeles, CA 90041        |   Unfortunately, he never told us what kind
                             |   it was."  -Word Perfect to PCWrite manual
   t_pascal@{{{cub,jaguar,cheetah}.math},bobcat,cheshire,tiger}.oxy.edu 

From parc.xerox.com!pavel Wed Sep  2 15:57:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "2" "September" "1992" "15:50:09" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "22" "Re: Bug in read() and release 1.7.0" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 2 Sep 1992 15:57:18 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11914>; Wed, 2 Sep 1992 15:55:51 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11909>; Wed, 2 Sep 1992 15:52:43 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 2 Sep 1992 15:50:42 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11901>; Wed, 2 Sep 1992 15:50:20 PDT
Received: by lambda.parc.xerox.com id <58372>; Wed, 2 Sep 1992 15:50:10 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002BBD00
In-Reply-to: <9208242324.AA10618@casbah.acns.nwu.edu>
Message-ID: <92Sep2.155010pdt.58372@lambda.parc.xerox.com>
References: <9208242255.AA02126@turquoise.cm.cf.ac.uk>
	<9208242324.AA10618@casbah.acns.nwu.edu>
Date:	Wed, 2 Sep 1992 15:50:09 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	hpa@nwu.edu
cc:	Andrew.Wilson@computing-maths.cardiff.ac.uk, moo-cows@parc.xerox.com
Subject: Re: Bug in read() and release 1.7.0

There was, indeed, a bug in read() such that, if there was no pending input on
the connection (i.e., the read()ing task had already gobbled it up) and the
connection was then closed (from either side), then the read()ing task would
never resume.  This has now been fixed; the fix will appear as part of release
1.7.0, hopefully coming later this week.

Brief status report on 1.7.0:

Ref-counting is done and appears to be working wonderfully.  We've also
dramatically improved the performance of property-value lookup, which was the
next speed bottleneck in line.  Also, the notion of `clear' property values,
through which you can see the value of that property in the parent, is now
implemented and working.  This latter feature should allow for a major space
savings, since child objects whose properties haven't been changed since
creation have all their properties clear, so that they don't duplicate the
values in the parent.  We're going to apply this notion to LambdaMOO's DB
retroactively today or tomorrow and we're expecting a major drop in space.

The new multi-networking stuff, also scheduled for 1.7.0, is not yet ready, but
what I've done so far makes me hopeful that it shouldn't be much longer.

	Pavel

From xerox.com!parc.xerox.com.PARC Wed Sep  2 22:06:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "2" "September" "1992" "20:20:03" "-0700" "Michael Richardson" "mcr@latour.uucp " "<9209030320.AA21917@sandelman.ocunix.on.ca>" "26" "Re: Bug in read() and release 1.7.0" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 2 Sep 1992 22:06:43 -0700
Received: from mail.uunet.ca ([142.77.1.1]) by alpha.xerox.com with SMTP id <11937>; Wed, 2 Sep 1992 22:06:20 PDT
Received: from ocunix by mail.uunet.ca with UUCP id <10812>; Thu, 3 Sep 1992 01:06:13 -0400
Received: by micor.OCUnix.On.Ca (smail2.5)
	id AA27919; 2 Sep 92 23:43:35 EDT (Wed)
Received: by sandelman.ocunix.on.ca id AA21917
  (5.65a/IDA-1.4.2); Wed, 2 Sep 92 23:20:17 -0400
Message-Id: <9209030320.AA21917@sandelman.ocunix.on.ca>
In-Reply-To: Pavel Curtis <Pavel@parc.xerox.com>
       "Re: Bug in read() and release 1.7.0" (Sep  2,  6:50pm)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Date:	Wed, 2 Sep 1992 20:20:03 -0700
From:	mcr@latour.uucp (Michael Richardson)
To:	Pavel Curtis <Pavel@parc.xerox.com>
Cc:	moo-cows@parc.xerox.com
Subject: Re: Bug in read() and release 1.7.0

On Sep 2,  6:50pm, Pavel Curtis wrote:
} next speed bottleneck in line.  Also, the notion of `clear' property values,
} through which you can see the value of that property in the parent, is now
} implemented and working.  This latter feature should allow for a major space
} savings, since child objects whose properties haven't been changed since
} creation have all their properties clear, so that they don't duplicate the
} values in the parent.  We're going to apply this notion to LambdaMOO's DB
} retroactively today or tomorrow and we're expecting a major drop in

  I think the most important aspect of this from the MOO programmer's
point of view is that properties could now `copy-on-write'. There was
a bunch of non-MUD things I was doing with MOO (1.2 I think) last year
that was really begging for `copy-on-write'
  I assume that it is possible to restore the `clear' state to a
property?



-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca     Bell: (613) 237-5629
SCHOOL: 192228@physics.carleton.ca      




From parc.xerox.com!pavel Thu Sep  3 11:52:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "3" "September" "1992" "11:44:05" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "11" "Re: Bug in read() and release 1.7.0" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Thu, 3 Sep 1992 11:51:50 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11958>; Thu, 3 Sep 1992 11:50:40 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11943>; Thu, 3 Sep 1992 11:47:18 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 3 Sep 1992 11:44:36 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11950>; Thu, 3 Sep 1992 11:44:26 PDT
Received: by lambda.parc.xerox.com id <58372>; Thu, 3 Sep 1992 11:44:13 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002BCC7C
In-Reply-to: <9209030320.AA21917@sandelman.ocunix.on.ca>
Message-ID: <92Sep3.114413pdt.58372@lambda.parc.xerox.com>
References: <9209030320.AA21917@sandelman.ocunix.on.ca>
	<Pavel@parc.xerox.com>
Date:	Thu, 3 Sep 1992 11:44:05 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	mcr@sandelman.ocunix.on.ca
cc:	moo-cows@parc.xerox.com
Subject: Re: Bug in read() and release 1.7.0

> Date:	Wed, 2 Sep 1992 20:20:03 -0700
> From:	mcr@latour.uucp (Michael Richardson)
> 
>   I assume that it is possible to restore the `clear' state to a
> property?

Yes, with the new `clear_property(obj, name)' built-in function.  Also, you can
test for `clarity' with the new `is_clear_property(obj, name)' built-in
function.

	Pavel

From uunet.uu.net!cbmvax!lynx!davidm Tue Sep  8 23:02:08 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "8" "September" "1992" "12:32:14" "-0700" "David Miller" "cbmvax!lynx!davidm@uunet.uu.net" nil "22" "Re: LambdaMOO on SVR4" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 8 Sep 1992 23:02:06 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <13309>; Tue, 8 Sep 1992 23:01:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <13308>; Tue, 8 Sep 1992 22:58:41 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 8 Sep 1992 22:55:28 -0700
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <13308>; Tue, 8 Sep 1992 22:55:05 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA12126; Tue, 8 Sep 92 17:57:28 -0400
Received: from cbmvax.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 164338.19710; Tue, 8 Sep 1992 16:43:38 EDT
Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore 2/8/91)
	id AA05695; Tue, 8 Sep 92 15:43:57 EDT
X-Mailer: ELM [version 2.3 PL11 913261353]
Content-Type: text
Content-Length: 537
X-NS-Transport-ID: 08002008D0FD002C13B9
Message-ID: <715980735.AA24297@lynx.cbm.commodore.com>
Date:	Tue, 8 Sep 1992 12:32:14 -0700
From:	David Miller <cbmvax!lynx!davidm@uunet.uu.net>
To:	moo-cows@parc.xerox.com (LambdaMOO Mailing List)
cc:	moo-cows@parc.xerox.com (LambdaMOO Mailing List)
Subject: Re: LambdaMOO on SVR4
Reply-to: cbmvax!lynx!davidm@uunet.uu.net

Damn!  That's what I get for fiddling with the patchfile 
rather than regenerating it...

The second argument should be F_SETFL, not F_GETFL.

<sigh>


+ #ifdef	USE_POSIX
+     if (fcntl(fd, F_GETFL, yes | O_NONBLOCK) == -1) {
+ 	log_perror("Setting network connection flags to non-blocking");
+ 	return;
+     }
+ #else
+     if (fcntl(fd, F_GETFL, yes | O_NDELAY) == -1) {



-- 
DavidM			CATS - Commodore Applications and Technical Support
+1 215 431 9425		davidm@cbmvax.commodore.com
"Commodore Amiga 3000UX - Born to Run UNIX SVR4"

From nic.gac.edu!eostrom Wed Sep  9 15:55:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "9" "September" "1992" "15:43:47" "-0700" "Erik Ostrom" "eostrom@nic.gac.edu " nil "108" "clear properties, possible hazard" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Wed, 9 Sep 1992 15:55:24 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <15454>; Wed, 9 Sep 1992 15:54:35 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <15455>; Wed, 9 Sep 1992 15:48:56 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 9 Sep 1992 15:46:23 -0700
Received: from gacvx1.gac.edu ([138.236.1.1]) by alpha.xerox.com with SMTP id <15449>; Wed, 9 Sep 1992 15:45:41 PDT
Received: from dion (dion.gac.edu) by gacvx1.gac.edu with PMDF#10127; Wed, 9
 Sep 1992 17:47 CST
Received: by dion (NeXT-1.0 (From Sendmail 5.52)/GACnet-2.0-NeXT) id AA00251;
 Wed, 9 Sep 92 17:43:47 CDT
X-NS-Transport-ID: 08002008D0FD002C2C8C
Message-ID: <9209092243.AA00251@dion>
Date:	Wed, 9 Sep 1992 15:43:47 -0700
From:	eostrom@nic.gac.edu (Erik Ostrom)
To:	moo-cows@parc.xerox.com
Subject: clear properties, possible hazard

For those who don't read *core-db-issues@LambdaMOO:

Message 679 on *Core-DB-Issues (#8175):
Date:     Mon Sep  7 10:14:14 1992 PDT
From:     JoeFeedback (#2612)
To:       *Core-DB-Issues (#8175)
Subject:  Re: .help_msg

>  The .help_msg shouldn't be a problem with clear properties; it
>  will no longer get copied to children.  The only problem is with
>  existing children of generics with large .help_msg's... And it's
>  easy enough to just @clearp those. :)

Actually, it's so easy, it's ALREADY DONE.  New .help_msg properties will be
set clear on descendants; and someone went through and cleared all properties
that are the same as those on their parents (Is that clear?), or at least all
those that I've looked at.

This is a kind of warning: The behavior of clear properties is not the same as
the prior behavior of properties equal to their parents', because changing a
parent's property will drag all the clear properties along with it.  This may
be a problem if you have a usable object that others' objects are descended
from.  For example, if you have a shoelace with a .tied_property, and people
have made children of it, and your shoelace's .tied and another shoelace's
.tied happened to both be empty when the Great Clearing was done, then tying
your shoelace to someone will *also tie someone else's shoelace*.  For that
matter, new children of your shoelace will be in the same predicament, and if
the .tied property is +c (never mind how unlikely that is), then I suspect
you'll have no way of clearing it except printing instructions to the new
owner, and hoping e's a programmer.
--------------------------

More comment on the situation: yduJ and others seem convinced that
this (dragalong) is the way properties should have worked all along.
I'm pretty convinced that it's a bug.  However, it's possible to
compensate for newly created objects whose properties you don't want
clear.  The programmer must make the important properties !c (which I
think is generally a good idea anyway), and write something like this
(from Sick's message on *core-db-issues):

	this.<prop> = parent(this).<prop>;

in the parent object's :initialize verb.

There are two cases that this doesn't provide for:

	1) A mass clearing of properties, such as the one that was
just done on LambdaMOO.  While such a clearing seems necessary if
clear properties (under the current implementation) are to do any
good, it means that people have to go through their objects and make
sure no properties are clear that shouldn't be.  In a huge
many-programmer database like LambdaMOO, it's impossible to get
everyone to check; in a large multi-programmer db, I'd guess it would
merely be painful.

	2) chparent().  When I suggested (again on *core-db-issues)
that you could take care of everything with a good :initialize verb,
APHiD pointed out that ":initialize() only works some of the time
since it isn't called by @chparent."  chparent() is a major pain
because, unlike create() and recycle(), it doesn't let any of the
objects involved know what's going on.  (Among other things, this is
the only reason the LambdaMOO Helpful Person Badges are all owned by
me--the topic database can't afford to have a badge chparented without
being notified.)

So anyway, if clear properties are going to stay, and maintain their
behavior, we really need for chparent() to call a verb, or, more
likely, two verbs.  Blackbriar created a model of this on ChaosMOO, in
which $object_utils:chparent did, in part:

	... stuff involving chparent(victim, new_parent)...
	new_parent:get_a_kid(victim, old_parent);
	old_parent:lose_a_kid(victim, new_parent);

Another possibility would be:

	victim:will_chparent(new_parent);
	... stuff involving chparent(victim, new_parent)...
	victim:did_chparent(old_parent);

This presumably has roughly the same effect, but it allows
object-specific code to be executed, and it's somewhat simpler.  On
the other hand, both of these schemes can mess up ancestors if a verb
anywhere along the line doesn't pass(@args).

We could discuss specifics some more, but I think chparent()
desperately needs some form of notification.
--------------------------

The other option is changing clear properties.  Clear properties could
go away, which would be sad, because they save space.  Alternatively,
clear properties could not be dragged along with their parents, in
which case we could get rid of the clear_property() and
is_clear_property() primitives, since clarity would be, well,
transparent.  This would still save space; however, it would involve
unclearing a number of properties (and possibly clearing properties
that suddenly become in line with the parent) on every property
assignment.  This might be a drag.  On the other hand, changing
properties on parent objects probably doesn't happen all that often.

I guess there are two points to this message: a caution about the
behavior of clear properties, and a suggestion that _something_ needs
to be changed, whether it be chparent(), clear properties, or
something I haven't thought of.  I'd like to see some sort of
discussion on this, at any rate; the present situation makes me
uncomfortable, but I'm not sure about the proper way to change it.

Erik/JoeFeedback

From cheetah.math.oxy.edu!t_pascal Thu Sep 10 09:14:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "10" "September" "1992" "08:52:28" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "51" "Random musings..." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 10 Sep 1992 09:14:37 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <15637>; Thu, 10 Sep 1992 09:12:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <15621>; Thu, 10 Sep 1992 09:08:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 10 Sep 1992 09:05:42 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <15623>; Thu, 10 Sep 1992 09:05:10 PDT
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <15622>; Thu, 10 Sep 1992 09:03:34 PDT
Received: from cub.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA06093; Thu, 10 Sep 92 08:52:30 PDT
Received: by cub.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA05584; Thu, 10 Sep 92 08:52:28 GMT-0700
X-NS-Transport-ID: 08002008D0FD002C3881
Message-ID: <9209101552.AA06093@cheetah.math.oxy.edu>
Date:	Thu, 10 Sep 1992 08:52:28 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	moo-cows.PARC@xerox.com
Subject: Random musings...


Well, since we now have server_log(), the "DISCONNECT" and "CONNECT"
messages can be moved into :disfunc() and #0:connect_player(), respectively.
"ACCEPT" and "CLINT DISCONNECTED" messages are harder to do...  What
about a :break_disfunc() which would be called if the player's link
goes dead by methods other than boot_player().  On a MOO like GodNet,
this could give finer distinction between quiting and losing one's link
accidentally -- additionally, "CLIENT DISCONNECTED" messages could move
into the database.  Actually, these changes are minor, probably worthless,
but it allows flexibility above the server level.

By the way, I am terribly glad that properties have been fixed, I've been
meaning to file bug reports and holler, but it's been done. :)  As to the
posting about changing the parent's properties and "dragging" all the
childrens' properties as well...  That is how it is supposed to be.  And
in theory, if an object has parents, it should not be used as a dynamic
object.   Thus, if you have a $shoe, you should only change $shoe.tied_lace
if you want the children to have the default value of $shoe.tied_lace
changed.  The same holds for verbs --  if you change a verb on a parent,
any non-shielded child will inherit the changes.

As far as chparent()'ing goes, I like blackbriar's model, but I do so
terribly hate to have the server calling verbs in the database...  This is
because the server should sit under the database, and not reach in and muck
with things... (It's unavoidable with things like .contents, .owner and flags)
I would like to keep the server in its place, as much as possible.  The
solution that comes to mind is to make a lot of server calls wizard-only
and write wrappers inside the db.  That way, the chparent() could be made
better, and the server doesn't interfere or make assumptions.

One last thing...  I wonder if it would be possible to have a makefile
switch called -DNOT_DISK_BASED which would keep the server in the old mode...
The reason I say this is because of a physical law of entropy, which in
computer science goes, "One trades space for cpu".  That is, if the server
is going to take less memory, you're going to use more cpu to manage the
space savings...  For some of us, memory is cheaper than cpu.  Also, I don't
know if short circuiting the swapping algorithm the OS provides is a good
thing.  What happens when you have your disk based server, and part of it
gets swapped, anyway? :)  If the swapping algorithm in the OS is broken,
then it should be fixed, not worked around.  I'll stop here, since I've
taken a lot of space, and this is probably a *very* unpopular view :) :)

Have fun.


---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
       t_pascal@{{{cub,cheetah,jaguar}.math},tiger,cheshire}.oxy.edu

From doc.ic.ac.uk!mjb Thu Sep 10 09:46:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "10" "September" "1992" "09:36:45" "-0700" "Matthew Jude Brown" "mjb@doc.ic.ac.uk" nil "44" "Re: Random musings..." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 10 Sep 1992 09:46:34 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <15634>; Thu, 10 Sep 1992 09:45:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <15630>; Thu, 10 Sep 1992 09:41:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 10 Sep 1992 09:39:40 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <15623>; Thu, 10 Sep 1992 09:39:22 PDT
Received: from frigate.doc.ic.ac.uk ([129.31.81.223]) by alpha.xerox.com with SMTP id <15618>; Thu, 10 Sep 1992 09:38:35 PDT
Received: from doc.ic.ac.uk by frigate.doc.ic.ac.uk 
          id <17170-0@frigate.doc.ic.ac.uk>; Thu, 10 Sep 1992 17:36:45 +0100
X-NS-Transport-ID: 08002008D0FD002C3931
In-Reply-to: "t_pascal@cheetah.math.oxy.edu's message of Thu, 10 Sep 1992 08:52:28 PDT <9209101552.AA06093@cheetah.math.oxy.edu>"
Message-ID: <92Sep10.093835pdt.15618@alpha.xerox.com>
Date:	Thu, 10 Sep 1992 09:36:45 -0700
From:	Matthew Jude Brown <mjb@doc.ic.ac.uk>
To:	t_pascal@cheetah.math.oxy.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: Random musings...

T_Pascal <t_pascal@cheetah.math.oxy.edu> writes:
>One last thing...  I wonder if it would be possible to have a makefile
>switch called -DNOT_DISK_BASED which would keep the server in the old mode...
>The reason I say this is because of a physical law of entropy, which in
>computer science goes, "One trades space for cpu".  That is, if the server
>is going to take less memory, you're going to use more cpu to manage the
>space savings...  For some of us, memory is cheaper than cpu.  Also, I don't
>know if short circuiting the swapping algorithm the OS provides is a good
>thing.  What happens when you have your disk based server, and part of it
>gets swapped, anyway? :)  If the swapping algorithm in the OS is broken,
>then it should be fixed, not worked around.  I'll stop here, since I've
>taken a lot of space, and this is probably a *very* unpopular view :) :)

I don't think this [option to use the old server model] will be
necessary. I should imagine (having had a tiny bit of experience with
disk-based servers) that the cache size will be tuneable. If you've
got lots of memory, bump up the cache!  Make it large enough, and for
all practical purposes you'll be running memory-based.

'Short circuiting the swapping algorithm the OS provides', as you put
it, IS a good idea. Why? Simply that the OS's swapping algorithm is
horribly generic and knows little about the make-up of the data it's
working with. The MOO, on the other hand, knows what data is what, and
can therefore increase the likelihood of data being in core when it's
needed, with obvious speed improvements.

Problems will, of course, occur on systems where the MOO database is
held on slow disk - eg. on AFS. Here it's probably best to run with a
large cache in order to use the much faster local swap.

It has to be kept in mind that the OS swapping mechanism itself will
likely be much more rapid than any system the MOO itself can provide,
since the OS swaps in and out pages of about 4Kb a time, possibly
using much lower level disk access, and often to a dedicated local
swap device. In-server disk basing only wins if the increase in
caching efficiency more than counterbalances this.

-Morven/Matt

-- 
| Matthew J. Brown  | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk  | Imperial College,  | lectures He wouldn't have created |
| mjb02@cc.ic.ac.uk | 180 Queen's Gate   | double-sided photocopiers.        |
| Morven on Lambda  | LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

From theory.cs.mankato.msus.edu!nop Thu Sep 10 12:29:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "10" "September" "1992" "12:16:55" "-0700" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "4" "Random musings..." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 10 Sep 1992 12:29:07 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <15672>; Thu, 10 Sep 1992 12:27:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <15675>; Thu, 10 Sep 1992 12:23:46 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 10 Sep 1992 12:18:45 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <15647>; Thu, 10 Sep 1992 12:18:11 PDT
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <15658>; Thu, 10 Sep 1992 12:17:09 PDT
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA20092; Thu, 10 Sep 92 14:16:55 -0500
X-NS-Transport-ID: 08002008D0FD002C3CB5
In-Reply-to: "t_pascal@cheetah.math.oxy.edu's message of Thu, 10 Sep 1992 08:52:28 PDT <9209101552.AA06093@cheetah.math.oxy.edu>"
Message-ID: <9209101916.AA20092@theory.cs.mankato.msus.edu>
Date:	Thu, 10 Sep 1992 12:16:55 -0700
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	t_pascal@cheetah.math.oxy.edu
cc:	moo-cows.PARC@xerox.com
Subject: Random musings...

> Well, since we now have server_log(), the "DISCONNECT" and "CONNECT"
> messages can be moved into :disfunc() and #0:connect_player(), respectively.

:disfunc on what?

From cs.stanford.edu!crew Thu Sep 10 15:10:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "10" "September" "1992" "15:05:30" "-0700" "Roger Crew" "crew@cs.stanford.edu" nil "229" "doing :initialize/:recycle \"right\"" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 10 Sep 1992 15:10:38 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <15443>; Thu, 10 Sep 1992 15:10:12 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <15693>; Thu, 10 Sep 1992 15:07:49 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 10 Sep 1992 15:05:52 -0700
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <15621>; Thu, 10 Sep 1992 15:05:26 PDT
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA28226; Thu, 10 Sep 92 15:05:31 PDT
X-NS-Transport-ID: 08002008D0FD002C3FAD
Message-ID: <9209102205.AA28226@Xenon.Stanford.EDU>
Date:	Thu, 10 Sep 1992 15:05:30 -0700
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: doing :initialize/:recycle "right"

...Erik/JoeF just triggered one of my backlogged drafts...  
...Sorry about the length on this, it's been growing for a while...

>	 2) chparent().  ... is a major pain because, unlike create()
>    and recycle(), it doesn't let any of the objects involved know
>    what's going on.

The problem isn't just chparent().  create() and recycle() don't always let
the object know either.  Yes, :initialize and :recycle get called
respectively, but it may not necessarily be the :initialize/:recycle you wrote
if we're talking about an object that is grandchild or lower in the hierarchy.

Consider, for example, the current problem we have with .owned_objects where 
we rely on all :initialize and :recycle verbs to actually pass(@args)
somewhere in order to ensure that #1:initialize/recycle eventually get
called to update .owned_objects.  There are lots of other things that should 
be handled using :initialize/:recycle (e.g., the quota system) that can't 
currently be done that way precisely because we can't trust those routines 
to always be called

The purpose of :initialize/:recycle as I see it:

  making it possible to maintain some invariant governing the descendants 
  of a given object, 

much the way :accept/:enterfunc/:exitfunc can be used to maintain an
invariant governing the contents of a given room.  A typical invariant might be

  "for every descendant of this object, 
   there is an entry on such-and-such a list".

Consider LambdaCore's $exit:recycle(), which tries to keep the corresponding 
room's .exits and .entrances lists up to date and thus guarantee that these 
lists don't contain invalid objects.

Problems:

1.  [as noted above]  There is no guarantee that a particular object's
    :initialize/:recycle verb gets called, whether because of a descendant
    refusing to pass(@args) or someone's use of chparent().

Adding hooks to chparent() is only a partial solution and partial solutions
are basically worthless, since if you can't trust the mechanism you have to 
be constantly checking that it hasn't been circumvented, which usually ends 
up being more effort than to simply do things a different way.  

So I think we need something more comprehensive.  First let's brush aside an
easier problem:

2.  There is no way to distinguish between a legitimate call to :initialize(),
    one resulting from a call to the create() builtin and an ordinary verb 
    call.  The callers() stack looks the same in both cases.  

This is actually a general problem with server hooks, though for top-level
hooks like :server_started or :do_login_command, it suffices to make sure
there aren't any callers.  However, for :accept, :exitfunc, :enterfunc,
:initialize and :recycle, life is not so easy.

Seeing as the task_permissions and object-id of the entity attempting the
move(), create() or recycle() operation are relevant in :exitfunc, etc...,
modifying the behavior of caller_perms() or caller is probably not the right
way to go here.  Nor do I like the idea of modifying callers(), never mind
that anything that increases the dependence on callers() is a lose IMHO.

I think the simplest answer here is to put the x verbflag to its intended 
use, i.e., !x means only the server can call this verb.  The only change
required would be to have the server recognize -x verbs when searching for 
hook verbs the way it does when it searches for command verbs.  This way,
if, say, I were to make an object:exitfunc -x, I would be guaranteed that 
only a move(object) call could invoke it.

To get back to problem (1) and what to do about it, the key point is that in
order for hook routines (:initialize, etc...) to be useful there has to be a
way to guarantee that they always get called, whether you use create() or some
bizarre combination of chparent()s.  What exactly this means is unclear
though:

      a        suppose I want to chparent(x,e), and suppose each of
     / \       b, c, d, and e is trying to enforce some particular condition
    b   d      on each of their descendants, then something has to ensure
   /     \     that all 4 of those hooks (call them :gain_a_kid/:lose_a_kid 
  c       e    for now) get called.  Then we're in for trouble when these hook
 /             routines can themselves do arbitrarily bad things to the 
x              inheritance hierarchy.

Consider the case where one of c:lose_a_kid, b:lose_a_kid, or d:gain_a_kid 
does chparent(e,x).  With the restriction on properties, there are other fun 
possibilities in which b:lose_a_kid adds a property to x that is defined on e.

Where should x be left in the heirarchy when bad things happen?  If we don't
choose a good place, then that leaves open potential ways to circumvent these
hooks.

[...I just deleted 3 huge paragraphs describing possible locking mechanisms
    to prevent hook routines from screwing with the inheritance hierarchy.  
    I've decided *that* cure is worse than the disease...]

The bottom line is that chparent() is just too damn complicated; if it has
to call a sequence of hooks --- and I think there's no way around this ---
then there's no way it should be viewed as an atomic operation.  Likewise for
create() and recycle(), they are all fairly complicated beasts that we should
reduce to a simpler set of building blocks.

So here's the proposed set of builtins to take their places:

new(owner)   (I'd really like to call this one "create" but the name is taken.)
  raise E_PERM unless caller_perms().wizard
  => an anonymous child of #-1 having the given owner

destroy(object)  
  raise E_PERM unless caller_perms().wizard
  raise E_INVARG if (parent(object)!=#-1)
  remove all properties and verbs from object
  render object invalid

specialize(object,newparent)
  (raise E_PERM unless caller_perms() controls object i.e. == owner or wizard)
  (raise E_PERM unless either newparent.f or caller_perms() controls newparent)
   raise E_RECMOVE if object == newparent
   raise E_INVARG  if parent(object)!=parent(newparent)
   raise E_INVARG  if some property of newparent is defined 
                      on object or a descendant
    1. change the parent of object to newparent, 
    2. initialize slots for each of properties(newparent).
    3. If newparent has its own :initialize verb, call it with this==object.
     (object may have its own :initialize verb but that should be ignored here)

generalize(object)
   raise E_INVARG unless valid(parent(object))
  (raise E_PERM unless caller_perms() controls object OR parent(object))
    1. if the parent has its own :finalize verb, call it with this==object,
       (object may have its own :finalize verb but that should be ignored here)
   raise E_SCREWED if parent(object) has changed
    2. remove all parent property slots
    3. change object's parent to parent(parent(object))

Then, create() is really a new() followed by a succession of specialize()s,
recycle() is really a succession of generalize()s followed by a destroy(),
chparent() is... you get the idea.  Now, if I have an object and you want to
make a child of it, you have no choice but to first create a sibling --- nor
do I have to concern myself with what contortions you have to go through to
obtain that sibling.  Then you have to call specialize() and then *my*
:initialize() verb is called.  Likewise if you have a descendent of my object
and you want to recycle it or otherwise get it out from under, you first have
to work it up to being a direct child --- again, I won't care how you do this
--- and then do generalize() which unavoidably calls my :finalize() verb.

With generalize, there is an added wrinkle in that, in the vanilla scheme,
:finalize is free to punt your object back down to being a grandchild or
lower.  Note that :finalize really does have to go first (i.e., before the
actual parent change) since it will probably need access to property values
that will go away when the parent change happens.  Strictly speaking this is
not a problem in that, wherever my finalize decides to move your object within
its family, the appropriate :initialize/:finalize on descendent objects will
be called and things will remain in a consistent state even though the error
E_SCREWED eventually gets raised.

Still, having me being able to trap your object underneath mine in the
inheritance hierarchy --- which, by the way, would also prevent you from
recycling it --- might be regarded as a problem, much like trapping exitfuncs.
If one does not wish to regard it as strictly a "social" problem (i.e., best
answered by putting "don't do this" in `help manners'), there is a relatively
simple locking mechanism that will take care of it: give every object a lock
bit, set it before calling :finalize, reset it when :finalize returns or bombs
out, then have any attempt to specialize or generalize a locked object raise
an error.  That way :finalize has all of the information it needs and can
still chparent other objects (e.g., voodoo dolls) when necessary.

There isn't a similar problem with specialize() since the :initialize call is
at the very end so nothing can be left inconsistent.  Anyway, the worst that
:initialize can do is bounce the object back above the parent or kick it
down lower.  Neither of these can even be considered a "social" problem; the
former provides a way to do away with the check for

  (raise E_PERM unless either newparent.f or caller_perms() controls newparent)

that is, every object becomes +f by default and if you don't want it to be +f,
you put in a killer :initialize().  Notice now that having :initialize verbs be inherited takes on a different meaning than before.  If I want to make an entire subtree effectively -f, it's merely a matter of installing an :initialize on the root object that does

   root = ...;
   if(parent(this) == root && !$perm_utils:controls(caller_perms(),root))
     generalize(this);
   endif

The .f flag, by the way, doesn't currently exist; I'm just lobbying for a way
to control fertility independently of readablity (.r)

Other details:

(*) generalize() being usable by the parent object's owner as well as the
object's owner makes it possible to painlessly get rid of unwanted children,
which I think would be a good thing.

(*) The E_PERM checks that I've got in parentheses in specialize() and
generalize() are by analogy with what the current server does.  One may
instead want to make these new builtins be wizard-only and then leave the db
owner to decide who gets to use them and when.  

(*) I could easily see using specialize(#-1) in place of new() and having
generalize(obj) recycle obj if it has an invalid parent.  Thus we'd just
have 2 builtin functions for messing with the object hierarchy.  
I see this as a matter of taste.

(*) Yes, that *is* supposed to be :finalize rather than :recycle.  
In short, 
    :finalize => what my child should do when it wants to leave home
                 (i.e., clean up and lock the door behind him)
    :recycle  => what I should do before I die...
                 (i.e., write a will, etc...).  

Currently, :recycle is doing double duty.  With all of the child-cleanup 
functions pushed off onto :finalize, there's probably no need for a :recycle 
server hook.

(*) Re: backwards compatibility.  create() recycle() and chparent() can be
written in terms of the above builtins in moo-code.  A short term solution to
the problem of keeping existing code workable would be to have the create(),
recycle() and chparent() builtins continue to exist but merely call the
corresponding verbs on #0.

(*) Re: multiple inheritance: I think this should carry over without too much
difficulty.  Just read "add_parent()" in place of "specialize()" and
"delete_parent()" in place of "generalize()".  The general theme remains the
same:

   Don't try to create() all in one shot.  Rather, take a new() object and
   gradually maneuver it down the object tree/dag until it's where you want it.
   Likewise for recycle() and whatever the analogue to chparent() is 
   going to be (if any).

From media-lab.media.mit.edu!asb Mon Sep 14 20:29:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "September" "1992" "20:19:07" "-0700" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "22" "the verb editor" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 14 Sep 1992 20:29:14 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11800>; Mon, 14 Sep 1992 20:27:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11784>; Mon, 14 Sep 1992 20:24:27 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 14 Sep 1992 20:20:11 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11777>; Mon, 14 Sep 1992 20:19:43 PDT
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11784>; Mon, 14 Sep 1992 20:19:12 PDT
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA21419; Mon, 14 Sep 92 23:19:07 -0400
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD002C7608
Message-ID: <9209150319.AA21419@media-lab.mit.edu>
Date:	Mon, 14 Sep 1992 20:19:07 -0700
From:	asb@media-lab.media.mit.edu
To:	moo-cows.PARC@xerox.com
Subject: the verb editor


I'm not quite sure I understand the advantage of having the verb
editor be a separate place.  One of the wonderful things about MU*s
is that they encourage programming as a collaborative activity
which takes place in a social context.  The idea that you
need to be locked away in a room by yourself to edit your verbs
seems a little silly.

It seems to me that most of the ways that say, look, etc. are remapped
in the editor can be replaced with other commands.  For example, it's
cute that typing "look" gives you a list of editor commands, but I can
just as easily type "help @edit" or something similar.

Am I missing something about this?

-- Amy

p.s.  I have a feeling this would be difficult... but is it possible to
do an escape to your local system from moo?  What I'd like to do is
set things up so that you can invoke an editor that runs on your
local machine on your verb, and then pass the edited file back
to the moo server.

From ee.ualberta.ca!daum Mon Sep 14 21:46:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "September" "1992" "21:35:08" "-0700" "Ryan Daum" "daum@ee.ualberta.ca" nil "10" "Re: the verb editor" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 14 Sep 1992 21:46:06 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11796>; Mon, 14 Sep 1992 21:44:20 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11795>; Mon, 14 Sep 1992 21:42:19 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 14 Sep 1992 21:39:19 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11795>; Mon, 14 Sep 1992 21:35:58 PDT
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11794>; Mon, 14 Sep 1992 21:35:26 PDT
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA27738; Mon, 14 Sep 92 22:35:09 -0600
Full-Name: Ryan Daum
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD002C76B3
In-Reply-to: "<9209150319.AA21419@media-lab.mit.edu>; from \"asb@media-lab.media.mit.edu\" at Sep 14, 92 8:19 pmC822 h"
Message-ID: <92Sep14.213526pdt.11794@alpha.xerox.com>
Date:	Mon, 14 Sep 1992 21:35:08 -0700
From:	Ryan Daum <daum@ee.ualberta.ca>
To:	asb@media-lab.media.mit.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: the verb editor

> 
> p.s.  I have a feeling this would be difficult... but is it possible to
> do an escape to your local system from moo?  What I'd like to do is
> set things up so that you can invoke an editor that runs on your
> local machine on your verb, and then pass the edited file back
> to the moo server.
> 
	The EMACS client MUD.el (or MOO.el) does this quite well with C-c C-v, which opens an emacs buffer in which the code is present, and pressing C-c C-s sends it to the MOO to compile.



From dartmouth.edu!Michael.J.Fromberger Mon Sep 14 21:48:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "September" "1992" "21:33:19" "-0700" "Michael.J.Fromberger@dartmouth.edu" "Michael.J.Fromberger@dartmouth.edu" nil "17" "Re: the verb editor" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 14 Sep 1992 21:48:08 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11791>; Mon, 14 Sep 1992 21:47:41 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11798>; Mon, 14 Sep 1992 21:39:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Mon, 14 Sep 1992 21:35:36 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11777>; Mon, 14 Sep 1992 21:35:17 PDT
Received: from dartvax.dartmouth.edu ([129.170.16.4]) by alpha.xerox.com with SMTP id <11777>; Mon, 14 Sep 1992 21:34:46 PDT
Received: from prancer.dartmouth.edu by dartvax.dartmouth.edu (5.65+D4/4.4HUB)
	id AA14059; Tue, 15 Sep 92 00:33:30 -0400
X-NS-Transport-ID: 08002008D0FD002C76B1
Message-ID: <2034788@prancer.Dartmouth.EDU>
Date:	Mon, 14 Sep 1992 21:33:19 -0700
From:	Michael.J.Fromberger@dartmouth.edu
To:	asb@media-lab.media.mit.edu (asb@media-lab.media.mit.edu),
	moo-cows.PARC@xerox.com (moo-cows.PARC@xerox.com)
Subject: Re: the verb editor

--- asb@media-lab.media.mit.edu wrote:
p.s.  I have a feeling this would be difficult... but is it possible to
do an escape to your local system from moo?  What I'd like to do is
set things up so that you can invoke an editor that runs on your
local machine on your verb, and then pass the edited file back
to the moo server.

--- end of quoted material ---

Yes, it'd definitely be a big plus to be able to use emacs on verb code. 
Particularly in an XWindows environment (which is where I'm running the
server) where you can have a bunch of things open; it'd be nice to be able to
look at your code uninterrupted but still also be able tto interact with
other players...

-Sting
(Consultant, Computer Resource Ctr., Dartmouth College)

From netcom.com!whyanext!eric Mon Sep 14 22:44:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "September" "1992" "22:30:19" "-0700" "Eric Schwartz" "whyanext!eric@netcom.com " nil "55" "Emacs MUD.el client" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 14 Sep 1992 22:44:44 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11803>; Mon, 14 Sep 1992 22:43:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11794>; Mon, 14 Sep 1992 22:42:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Mon, 14 Sep 1992 22:38:21 -0700
Received: from netcomsv.netcom.com ([192.100.81.101]) by alpha.xerox.com with SMTP id <11674>; Mon, 14 Sep 1992 22:38:02 PDT
Received: from whyanext
Malformed-Field: .UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA27437; Mon, 14 Sep 92 22:37:31 PDT
Received: by  whyanext  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA02113; Mon, 14 Sep 92 22:30:19 PDT
Received: by NeXT Mailer (1.63)
X-NS-Transport-ID: 08002008D0FD002C772B
Message-ID: <9209150530.AA02113@whyanext>
Date:	Mon, 14 Sep 1992 22:30:19 -0700
From:	whyanext!eric@netcom.com (Eric Schwartz)
To:	netcom!parc.xerox.com!moo-cows@netcom.com
cc:	eric@netcom.com
Subject: Emacs MUD.el client
Reply-to: whyanext!eric@netcom.com

MOO-folk,


I'm having much trouble getting MUD.el to work.  Unfortunately I do  
not have much experience with emacs yet, but I've installed mud.el,  
.emacs, and .mud on two different machines, each with their own copy  
of emacs.

The first one immediately gives me an 'Unknown host  
whatever.host.I.tell.it.com' when I do 'M-m <ret>' on running emacs.

The second one at least _seems_ to try to connect, but after about a  
minute it will say 'Host whatever.com unreachable'.

On both these sites, I can success 'telnet lambda.parc.xerox.com  
8888'.  I've retrieved mud.el from a working site and haven't changed  
anything, and here are the other files:

.EMACS:
=======
(setq load-path (append '("/export/u1/myhomedirectory/") load-path))
(autoload 'mud "mud" nil t)
(define-key global-map "\eg" 'goto-line)
(define-key global-map "\em" 'mud)
(setq mud-show-page t)

	(substituting 'myhomedirectory' for the appropriate path)

.MUD:  (end of the file)
=====
server AlphaMOO         MOO      belch.berkeley.edu             7777
server LambdaMOO        MOO      lambda.parc.xerox.com          8888

default-server LambdaMOO
LambdaMOO name pass


Troubleshooting beyond this point is a problem for me--I've never  
_seen_ this work before, and I don't have the experience with emacs.

If anyone can offer some advice, I'm an eager listener.


Thanks,

Eric

--

Eric Schwartz
WhyaNeXT!eric@netcom.com (NeXTmail spoken here)
work )408( 279-7191
FAX  )408( 279-7167

"A five is an old four." --from 'The Silly Record' by Stoo Hample

From computing-maths.cardiff.ac.uk!Andrew.Wilson Thu Sep 17 08:28:08 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "17" "September" "1992" "08:03:49" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "5" "Game over man!" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 17 Sep 1992 08:27:58 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11585>; Thu, 17 Sep 1992 08:27:12 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11584>; Thu, 17 Sep 1992 08:22:39 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 17 Sep 1992 08:13:00 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11584>; Thu, 17 Sep 1992 08:12:27 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11581>; Thu, 17 Sep 1992 08:10:16 PDT
Via: uk.ac.cardiff.computing-maths; Thu, 17 Sep 1992 16:04:01 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <13832-0@sentinel.cm.cf.ac.uk>; Thu, 17 Sep 1992 16:04:02 +0100
X-NS-Transport-ID: 08002008D0FD002CA2F6
Message-ID: <9209171503.AA06254@emerald.cm.cf.ac.uk>
Date:	Thu, 17 Sep 1992 08:03:49 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows.PARC@xerox.com, Andrew.Wilson@computing-maths.cardiff.ac.uk
Subject: Game over man!


Hi,
	MOO-net.tar.Z is in /pub/MOO/contrib/moocode on parcftp.xerox.com.
Have, er, fun?
A.

From cheetah.math.oxy.edu!t_pascal Tue Sep 22 16:09:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "22" "September" "1992" "15:48:33" "-0700" "t_pascal@cheetah.math.oxy.edu" "t_pascal@cheetah.math.oxy.edu" nil "27" "Chaos Moo" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Tue, 22 Sep 1992 16:09:36 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11847>; Tue, 22 Sep 1992 16:08:47 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11937>; Tue, 22 Sep 1992 16:05:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 22 Sep 1992 16:02:31 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11847>; Tue, 22 Sep 1992 16:02:04 PDT
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <11854>; Tue, 22 Sep 1992 16:01:11 PDT
Received: from jaguar.math.oxy.edu by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA00890; Tue, 22 Sep 92 15:48:35 PDT
Received: by jaguar.math.oxy.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00922; Tue, 22 Sep 92 15:48:33 GMT-0700
X-NS-Transport-ID: 08002008D0FD002CF3D6
Message-ID: <9209222248.AA00890@cheetah.math.oxy.edu>
Date:	Tue, 22 Sep 1992 15:48:33 -0700
From:	t_pascal@cheetah.math.oxy.edu
To:	moo-cows.PARC@xerox.com
Subject: Chaos Moo


Dear friends,

I regret to say that the school year here at my college is beginning, and I
have been asked to remove the ChaosMoo.  I personally think that ChaosMoo
is not getting in anybody's way, nor is it fighting for cpu from other
applications.

I've made some bargaining, and the ChaosMoo can stay up for a few more weeks.
In that time, you will be able to retrieve any information you have on it...
After that, the database will be deleted (but I will keep a copy on tape).
If anybody wants the db, I can mail it, or put if up for ftp for a while.

It's not such a tragedy that a Moo has to be taken down, just that the
ChaosMoo was supposed to be a laboratory, for programming and experimentation.
Hopefully someone will be able to offer a site where such a thing can continue
(with the new server and new core db), but I have no more sites to offer.

My personal apologies.


---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
       t_pascal@{{{cub,cheetah,jaguar}.math},tiger,cheshire}.oxy.edu

From blackcat.math.oxy.edu!t_pascal Thu Sep 24 19:43:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "24" "September" "1992" "19:32:38" "-0700" "C. Regis Wilson" "t_pascal@blackcat.math.oxy.edu " nil "18" "ChaosMoo database" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Thu, 24 Sep 1992 19:43:34 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11758>; Thu, 24 Sep 1992 19:42:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11753>; Thu, 24 Sep 1992 19:39:21 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 24 Sep 1992 19:33:47 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11753>; Thu, 24 Sep 1992 19:33:22 PDT
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <11750>; Thu, 24 Sep 1992 19:32:48 PDT
Received: from  blackcat.math.oxy.edu  (blackcat) by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA00826; Thu, 24 Sep 92 18:32:39 GMT-0800
Received: by  blackcat.math.oxy.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA00367; Thu, 24 Sep 92 19:32:38 PDT
X-NS-Transport-ID: 08002008D0FD002D1F0D
Message-ID: <9209250232.AA00367@blackcat.math.oxy.edu>
Date:	Thu, 24 Sep 1992 19:32:38 -0700
From:	t_pascal@blackcat.math.oxy.edu (C. Regis Wilson)
To:	moo-cows.PARC@xerox.com
Subject: ChaosMoo database


I've had several requests for the ChaosMoo database...  I was going to
set up anonymous ftp for it, but the sysadmin wouldn't allow it, so
I've put it on beta.  It just needs to stay there for a week or less,
then it can go away.  It's 300K compressed, 900K uncompressed.  Here's
the info:

beta.xerox.com:/pub/MOO/contrib/ChaosMoo.db.Z

Thanks.


---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
       t_pascal@{{{cub,cheetah,jaguar}.math},tiger,cheshire}.oxy.edu

From ebs330.eb.uah.edu!claassen Mon Sep 28 15:56:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "28" "September" "1992" "15:30:38" "-0700" "ISE" "claassen@ebs330.eb.uah.edu (Arne Claassen )" nil "15" "Trying to program" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Mon, 28 Sep 1992 15:56:46 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11679>; Mon, 28 Sep 1992 15:55:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11674>; Mon, 28 Sep 1992 15:52:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 28 Sep 1992 15:46:12 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11653>; Mon, 28 Sep 1992 15:45:35 PDT
Received: from ebs330.eb.uah.edu ([146.229.4.1]) by alpha.xerox.com with SMTP id <11633>; Mon, 28 Sep 1992 15:45:03 PDT
Received: from ebs02.eb.uah.edu.uah.edu by ebs330.eb.uah.edu (4.1/SMI-4.1)
	id AA05825; Mon, 28 Sep 92 17:30:38 CDT
X-NS-Transport-ID: 08002008D0FD002D4DF3
Message-ID: <9209282230.AA05825@ebs330.eb.uah.edu>
Date:	Mon, 28 Sep 1992 15:30:38 -0700
From:	claassen@ebs330.eb.uah.edu (Arne Claassen (ISE))
To:	moo-cows.parc@xerox.com
Subject: Trying to program

Ok, here are a couple of things, that might be in a faq associated with this
list but i don't even know if such a faq exists and how to get it.

Anyway, I have gotten some places with the programmers manual from the moo FTP
site, but all in all it's rather hard to browse through... 
Now, how can i get the LambdaCoreUser Manual in normal text instead of textinfo?
And how can I decipher the Core Dump databases?

Simply, what my current task is, how do i create an object or modify the generic
announcer so that it announces things at a timed interval if there is anyone in
a certain set of rooms and keep that interval, regardless whether anyone does
or says something in one of those rooms.

Thanks,
FaithHealer

From parc.xerox.com!pavel Mon Sep 28 18:37:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "28" "September" "1992" "18:28:51" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "7" "Papers about MUDs?" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Mon, 28 Sep 1992 18:37:29 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11647>; Mon, 28 Sep 1992 18:37:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11675>; Mon, 28 Sep 1992 18:35:21 PDT
Received: by lambda.parc.xerox.com id <58373>; Mon, 28 Sep 1992 18:29:05 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002D50BE
Message-ID: <92Sep28.182905pdt.58373@lambda.parc.xerox.com>
Date:	Mon, 28 Sep 1992 18:28:51 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Papers about MUDs?
Reply-to: Pavel@parc.xerox.com

I'm looking to improve the completeness of my online and offline collections of
papers that mention or involve MUDs or IRC.  If you know of any such, please
send me a pointer to them, preferably to an on-line version.

Thanks!

	Pavel

From vortech.com!clay Tue Sep 29 12:35:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "29" "September" "1992" "13:22:17" "-0700" "Clay W. Luther" "clay@vortech.com " nil "9" "Moos" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Tue, 29 Sep 1992 12:35:27 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11776>; Tue, 29 Sep 1992 12:33:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11779>; Tue, 29 Sep 1992 12:30:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Tue, 29 Sep 1992 12:23:53 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11770>; Tue, 29 Sep 1992 12:23:32 PDT
Received: from psi.com ([192.67.6.2]) by alpha.xerox.com with SMTP id <11770>; Tue, 29 Sep 1992 12:22:44 PDT
Received: from [149.98.7.2] by psi.com (5.61/2.1-PSI/PSINet)
	id AA14465; Tue, 29 Sep 92 15:22:26 -0400
Received: from charon.vortech.com by vortech.com (4.1/SMI-4.0)
	id AA07154; Tue, 29 Sep 92 14:22:45 CDT
Received: from [149.98.10.61] (clay) by charon.vortech.com (4.1/SMI-4.1)
	id AA27281; Tue, 29 Sep 92 14:20:53 CDT
X-NS-Transport-ID: 08002008D0FD002D5D9F
Message-ID: <9209291920.AA27281@charon.vortech.com>
Date:	Tue, 29 Sep 1992 13:22:17 -0700
From:	clay@vortech.com (Clay W. Luther)
To:	moo-cows.PARC@xerox.com
Subject: Moos


Could someone please send me a list of active moos, with addresses, please?
 Thanks.

---
Clay W. Luther                               clay@vortech.com
Software Engineer                            Vortech Data, Inc.
Office (214) 994-1377                        Fax (214) 994-1310


From ac.grin.edu!DANKMYER Wed Sep 30 20:44:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "30" "September" "1992" "20:32:04" "-0700" "\"Loki, God of Mischief (Dankmyer,Kirt A)\"" "DANKMYER@ac.grin.edu" nil "9" "BTW" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Wed, 30 Sep 1992 20:44:09 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12009>; Wed, 30 Sep 1992 20:42:01 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12004>; Wed, 30 Sep 1992 20:38:01 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 30 Sep 1992 20:33:48 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12004>; Wed, 30 Sep 1992 20:33:37 PDT
Received: from AC.GRIN.EDU ([132.161.10.8]) by alpha.xerox.com with SMTP id <12004>; Wed, 30 Sep 1992 20:32:39 PDT
X-NS-Transport-ID: 08002008D0FD002D7A9C
Message-ID: <92Sep30.203239pdt.12004@alpha.xerox.com>
Date:	Wed, 30 Sep 1992 20:32:04 -0700
From:	"Loki, God of Mischief (Dankmyer,Kirt A)" <DANKMYER@ac.grin.edu>
To:	MOO-Cows.PARC@xerox.com
Subject: BTW

Hmmm, could someone send me a list of active MOOs as well? I need to update 
my .tinytalk file. Also, who in particular grabbed the ChaosMOO db?
	--Xiombarg
P.S. First MOOcows message! :)

--------
"You fool! You forgot the mattress covers! Now we're DOOMED!" --Ren
Eris * "Bob" * MST3K * R&S * Nomic * RPGs * Amigas * UNIX * Crowley * Industrial
dankmyer@ac.grin.edu -- dankmyer@grin1.bitnet -- Xiombarg on LambdaMOO

From computing-maths.cardiff.ac.uk!Andrew.Wilson Sat Oct  3 05:42:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "3" "October" "1992" "05:26:49" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "10" "Lambda MOOspaper." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 3 Oct 1992 05:42:06 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11877>; Sat, 3 Oct 1992 05:41:37 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11875>; Sat, 3 Oct 1992 05:38:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 3 Oct 1992 05:27:48 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11874>; Sat, 3 Oct 1992 05:27:16 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <11874>; Sat, 3 Oct 1992 05:26:49 PDT
Via: uk.ac.cardiff.computing-maths; Sat, 3 Oct 1992 13:26:42 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <25527-0@sentinel.cm.cf.ac.uk>; Sat, 3 Oct 1992 13:26:56 +0100
X-NS-Transport-ID: 08002008D0FD002DA38C
Message-ID: <9210031226.AA28707@topaz.cm.cf.ac.uk>
Date:	Sat, 3 Oct 1992 05:26:49 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	moo-cows.PARC@xerox.com
Subject: Lambda MOOspaper.



Hi,

	could some kind person please post me the three most recent
copies of the Lambda MOOspaper as the UK seems to have been temporarily
disconnected from the internet.

Thank you.
	Andy.

From parc.xerox.com!pavel Tue Oct  6 13:56:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "6" "October" "1992" "13:35:46" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "143" "Beta-testing LambdaMOO release 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 6 Oct 1992 13:56:35 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11867>; Tue, 6 Oct 1992 13:54:35 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11837>; Tue, 6 Oct 1992 13:49:35 PDT
Received: by lambda.parc.xerox.com id <58375>; Tue, 6 Oct 1992 13:41:41 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002DCED1
Message-ID: <92Oct6.134141pdt.58375@lambda.parc.xerox.com>
Date:	Tue, 6 Oct 1992 13:35:46 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Beta-testing LambdaMOO release 1.7.0
Reply-to: Pavel@parc.xerox.com

Today begins what I hope will be a short beta-testing phase for release 1.7.0
of the LambdaMOO server.  Because this server incorporates a number of new
networking implementations to enable the server's use on a broader array of
platforms (including single- and multi-user use on machines without a network),
it made sense to me that we should do one quick run-through of volunteers
trying to get the system up and running on as many kind of machines as
possible, using as many networking implementations as possible.  It should be
possible to get it running in at least some configuration on any UNIX machine,
and perhaps without too much trouble on other POSIX-compliant platforms.  None
of the configurations in this release will work on an MS/DOS machine.

Here's what I'd like a bunch of you to do for me (I *strongly* recommend that
you read this all the way through before starting):

1) Reply to this message (making sure that the reply is going to me only, not
   the whole MOO-Cows list) telling me the kind of hardware and operating
   system you're willing to test the server on.  I'll let you know if someone
   else is already doing that configuration, so that we avoid uselessly
   duplicating work.  If you don't hear back from me, assume that you're the
   one person testing that configuration and go for it.

2) FTP the distribution from host `parcftp.xerox.com', directory `pub/MOO',
   file `LambdaMOO-beta.tar.Z'; don't forget to use binary mode.  Also, using
   `ascii' mode, fetch `LambdaCore-12Aug92.db', renaming it to `LambdaCore.db'
   on your machine.  Unpack the compressed tar file in a clean directory.

3) Start some email to me, including the following information:
	Hardware type: >>Sun 3, SPARCstation, SGI, DECstation, etc.<<
	Operating System: >>SunOS 4.1.1, IRIX 3.3.3, Ultrix 4.2, etc.<<
	Compiler: >>Vendor supplied, GCC, etc.<<
	Predefined Symbols: >>See below<<
   The `Predefined Symbols' are those C preprocessor symbols that the compiler
   defines for every compilation; usually they include things like the machine
   name, the OS name, or some other name that uniquely identifies your hardware
   and software configuration.  On most machines, you can get the complete list
   simply by invoking your compiler with the `-v' option, in addition to the
   normal ones.  Try this, for example:
	cc -v -c match.c
   (and then delete match.o, if it exists).  The compiler should print out all
   of the commands it executed to do the compilation; the first of these
   probably has a bunch of arguments of the form `-Dfoo'.  I want you to make a
   list of all of the `foo's and put that in the `Predefined Symbols' field in
   your message to me.

4) Following the directions in the release, try to compile it first for
   SINGLE_USER mode.  Make a note or, much better, keep a verbatim copy of any
   warnings or errors you get from your compiler.  If it doesn't compile
   properly, see if you can figure out what I need to change in the code to
   make it do so.  If you can't figure it out, don't sweat it; I'll try to
   figure it out for myself.  Remember, the goal is that the server compile on
   your machine with *no* warnings or errors (except maybe for some in
   /usr/lib/yaccpar, which I don't control).

5) Add to your email message to me the copy you made of the warnings and/or
   errors you got in step 4, along with a description (preferably in diff -c
   format) of any changes you did to make it work.

6) If you couldn't get SINGLE_USER mode to compile, stop here and send me that
   email message.  With luck, I'll be able to get you over this hump and you
   can then continue.

7) If you *did* get SINGLE_USER mode to compile, try running it:

	./moo LambdaCore.db foo.db

   After loading the database, it should `connect' you to the server using the
   normal input and output streams of the server itself.  Type `co wizard' to
   log in and then `news' to make sure that commands work.  Then type `@quit'.
   You should be `disconnected' and then immediately `reconnected', getting the
   welcoming banner again.  This time don't log in but instead hit Ctrl-C (or
   whatever your usual `interrupt' key is); the server should go through its
   normal shutdown procedure, dumping the database into `foo.db'.

   If all this works normally, add something like this line to your message:

	SINGLE_USER mode passed the test.

   If it didn't work, then please describe in your message, as carefully as
   possible, what happened instead.  Then stop, sending that message off to me.

8) If you're still going, then it's time to test out each of the multi-user
   configurations in turn.  Edit `config.h' to comment out the #define for
   SINGLE_USER and to select one of the combinations of NETWORK_PROTOCOL and
   NETWOK_STYLE.  Add to your message a description of which one you're trying.
   Following the directions in the release, compile the server again.

9) As before, add to your message a copy of any warnings or errors you get, and
   try to make them go away, telling me what you did if you succeed.  If you
   can't get it to compile without errors, then give up on this configuration
   and go back to step 8 to try another one.

10) If you're here, then you've gotten some multi-user configuration to compile
   and you're ready to test it.  You will need three windows or terminals to do
   this properly.  In window 1, start the server:

	./moo LambdaCore.db foo.db

   In window 2, start a client for that server; if you're using the NP_LOCAL
   value of NETWORK_PROTOCOL, then use either `client_bsd' or `client_sysv', as
   appropriate.  Otherwise, use `telnet localhost 7777'.

   When you're connected in window 2, type `co wizard' to log in, and `news' to
   test whether normal commands work.  Then start a client in window 3; when
   connected, type `cr foo foo' to create a new character, `news' to test
   commands in that window, and `@quit' to disconnect.  There should be `foo
   has connected' and `foo has disconnected' messages in window 2.  Back in
   window 2, type `;shutdown("")' to shut down the server.  It should shut down
   normally, dumping the database into `foo.db'.

11) If all this worked fine, add a line to your message like this:

	Configuration NP_whatever/NS_whatever passed the test.

   If it didn't work right, then please add a careful description of what went
   wrong.

12) Repeat steps 8-11 for each of the four possible combinations of NP_* and
   NS_*.  Don't worry if some of them fail even to compile; so far, only SunOS
   has managed to make all of them work (unsurprising, since that's where I
   developed them).  When you've tested everything you can, and included in
   your message every warning, error, and failed test, send off that email to
   me.

Some of you have already sent messages about changes you made to get earlier
versions of the server to compile and run on various platforms.  Some of those
changes have been incorporated and others have not, based mostly on how much
time I had available when I received them.  Please send me those changes again
if the beta release seems still to need them.  Thanks.

By myself, I have already tested the server on the following platforms:

	SPARCstation running SunOS 4.1.1 (GCC)
	NeXT machine running NeXT Mach (vendor compiler == GCC)
	IBM RS/6000 running AIX version 3 (vendor compiler)
	SGI Iris running IRIX 4.0 (vendor compiler)

I will be testing on a SPARCstation running Solaris 2.0 (vendor compiler) as
well.  Everything else is up for grabs!

I thank you all very much in advance for helping make LambdaMOO easy for lots
of other people to bring up on their machines.

	Pavel/Haakon

From onet.edu!CAMP!seth Wed Oct  7 12:43:36 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "7" "October" "1992" "08:09:00" "-0700" "seth%CAMP@onet.edu" "seth%CAMP@onet.edu" nil "19" "How about this for a built-in..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Wed, 7 Oct 1992 12:43:31 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11987>; Wed, 7 Oct 1992 12:42:19 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11975>; Wed, 7 Oct 1992 12:38:17 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Wed, 7 Oct 1992 12:28:19 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11975>; Wed, 7 Oct 1992 12:11:50 PDT
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11963>; Wed, 7 Oct 1992 12:11:10 PDT
Received: from CAMP.Onet.Edu ([141.110.32.5])  for Moo-Cows@Xerox.Com
	by oscsunb.osc.edu (5.65c+KVa/920330.1102) id AA04190; Wed, 7 Oct 1992 15:11:06 -0400
Received: from campgate.onet.edu by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA29226; Wed, 7 Oct 92 15:10:09 EDT
Received: by campgate.onet.edu with Network-Courier
	id <2AD335F6@campgate.onet.edu>; Wed, 07 Oct 92 15:09:42
X-Mailer: Network Courier V2.1a
Encoding: 19 TEXT
X-NS-Transport-ID: 08002008D0FD002DE103
Message-ID: <2AD335F6@campgate.onet.edu>
Date:	Wed, 7 Oct 1992 08:09:00 -0700
From:	seth%CAMP@onet.edu
To:	Moo-Cows.PARC@xerox.com
Subject: How about this for a built-in...

How about a built-in that goes something like this:

  get_task_info()

  get_task_info() takes a task id as an argument and returns certain
  information on the given queued task in the following format:

    { task id, start time, ticks, clock_id, programmer, verb 
      location, verb name, line, `this' }

  [precisely the same information from queued_tasks()]

  If the task does not exist, E_ARGS is returned.

  If the task is owned by another player and the caller is not a 
  wizard, E_PERM is returned.

Seth / Blackbriar


From stony-brook.scrc.symbolics.com!yduJ Wed Oct  7 14:43:45 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "7" "October" "1992" "14:09:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "8" "How about this for a built-in..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Wed, 7 Oct 1992 14:43:34 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12000>; Wed, 7 Oct 1992 14:43:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11995>; Wed, 7 Oct 1992 14:40:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 7 Oct 1992 14:30:31 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11944>; Wed, 7 Oct 1992 14:06:51 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11982>; Wed, 7 Oct 1992 14:06:16 PDT
Received: from AVOCADO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1155177; 7 Oct 1992 17:06:38-0400
X-NS-Transport-ID: 08002008D0FD002DE35C
In-Reply-to: <2AD335F6@campgate.onet.edu>
Message-ID: <19921007210929.7.YDUJ@AVOCADO.SCRC.Symbolics.COM>
Date:	Wed, 7 Oct 1992 14:09:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	seth%CAMP@onet.edu, Moo-Cows.PARC@xerox.com
Subject: How about this for a built-in...


q = queued_tasks();
index = task_id() in $list_utils:slice(q,1);
if (index)
  return q[index];
else
  return E_ARGS;
endif

From camp.onet.edu!seth Wed Oct  7 15:27:49 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "7" "October" "1992" "14:40:27" "-0700" "Seth I. Rich" "seth%CAMP@onet.edu " nil "16" "Re: How about this for a built-in..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Wed, 7 Oct 1992 15:27:41 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12004>; Wed, 7 Oct 1992 15:27:03 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11974>; Wed, 7 Oct 1992 15:25:09 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58381>; Wed, 7 Oct 1992 15:13:14 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12004>; Wed, 7 Oct 1992 14:43:29 PDT
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11997>; Wed, 7 Oct 1992 14:41:29 PDT
Received: from CAMP.Onet.Edu ([141.110.32.5])  for Moo-Cows.PARC@xerox.com
	by oscsunb.osc.edu (5.65c+KVa/920330.1102) id AA06139; Wed, 7 Oct 1992 17:41:24 -0400
Received: from bell.glmtctpm by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA29786; Wed, 7 Oct 92 17:40:27 EDT
X-NS-Transport-ID: 08002008D0FD002DE411
Message-ID: <9210072140.AA29786@CAMP.Onet.Edu>
Date:	Wed, 7 Oct 1992 14:40:27 -0700
From:	seth%CAMP@onet.edu (Seth I. Rich)
Sender: seth@camp.onet.edu
To:	yduJ@stony-brook.scrc.symbolics.com, Moo-Cows.PARC@xerox.com
Subject: Re: How about this for a built-in...

yduJ tells me:

  q = queued_tasks();
  index = task_id() in $list_utils:slice(q,1);
  if (index)
    return q[index];
  else
    return E_ARGS;
  endif

I -know- that it can be done that way.  (I do it that way on LambdaMOO.)
But the server has that information easily at hand and it ought to be 
available... is there any reason why a get_task_info() shouldn't be a 
builtin?

Seth / Blackbriar

From parc.xerox.com!pavel Thu Oct  8 10:48:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "8" "October" "1992" "10:33:30" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "29" "Re: How about this for a built-in..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Thu, 8 Oct 1992 10:48:21 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11619>; Thu, 8 Oct 1992 10:46:33 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11591>; Thu, 8 Oct 1992 10:43:00 PDT
Received: by lambda.parc.xerox.com id <58372>; Thu, 8 Oct 1992 10:33:32 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002DF2C7
In-Reply-to: <9210072140.AA29786@CAMP.Onet.Edu>
Message-ID: <92Oct8.103332pdt.58372@lambda.parc.xerox.com>
References: <9210072140.AA29786@CAMP.Onet.Edu>
Date:	Thu, 8 Oct 1992 10:33:30 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	seth%CAMP@onet.edu, MOO-Cows@parc.xerox.com
Subject: Re: How about this for a built-in...

> Date:	Wed, 7 Oct 1992 14:40:27 -0700
> From:	seth%CAMP@onet.edu (Seth I. Rich)
> 
> is there any reason why a get_task_info() shouldn't be a builtin?

There is an important principle in language design, that of conceptual
parsimony.  In essence, it says you should make the set of primitive constructs
and concepts in the language as small and well-structured as possible.  One
should not, in particular, consider adding features to a language that can be
implemented in terms of existing primitives unless that implementation is
*intrinsically* too inefficient or too onerous for reasonable use.

In this case, the get_task_info() function can easily be written in MOO using
existing primitives, is very unlikely to be used in a context where the
difference in performance is noticeable, and is not significantly more
difficult to use as a verb than as a built-in function.  The principle of
conceptual parsimony, therefore, argues against making it a built-in function.

There are, of course, other principles of language design, other considerations
that should be taken into consideration, but I can't think of any that argue in
favor of making get_task_info() a primitive.  Let me therefore turn your
question around, Seth:

	Is there any reason why get_task_info() *should* be a built-in?

Conceptual parsimony says that new features are, if you will, guilty until
proven innocent.

	Pavel/Haakon

From parc.xerox.com!pavel Thu Oct  8 15:50:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "8" "October" "1992" "15:30:09" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "6" "Beta-testing addendum" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Thu, 8 Oct 1992 15:50:23 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11651>; Thu, 8 Oct 1992 15:48:16 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11665>; Thu, 8 Oct 1992 15:44:47 PDT
Received: by lambda.parc.xerox.com id <58374>; Thu, 8 Oct 1992 15:30:49 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002DF8E5
Message-ID: <92Oct8.153049pdt.58374@lambda.parc.xerox.com>
Date:	Thu, 8 Oct 1992 15:30:09 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Beta-testing addendum

I'm sorry, but I forgot to ask all of the testers to send me, along with their
test reports, a list of all of the settings they used in the top part of the
Makefile and in config.h.

Sorry for forgetting...
	Pavel

From uunet.uu.net!sun330!fnma.COM!s4uhkm Thu Oct  8 16:47:33 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "8" "October" "1992" "13:47:48" "-0700" "Howie Michalski" "s4uhkm@fnma.com " nil "40" "Re: How about this for a built-in..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Thu, 8 Oct 1992 16:47:31 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11631>; Thu, 8 Oct 1992 16:45:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11646>; Thu, 8 Oct 1992 16:44:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Thu, 8 Oct 1992 16:36:34 -0700
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <11625>; Thu, 8 Oct 1992 16:31:57 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11770; Thu, 8 Oct 92 19:18:50 -0400
Received: from almserv.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 173127.21984; Thu, 8 Oct 1992 17:31:27 EDT
Received: from paperwt.fnma.com by fnma.COM (4.1/SMI-4.1)
	id AA01481; Thu, 8 Oct 92 16:47:48 EDT
X-NS-Transport-ID: 08002008D0FD002DFA0A
Message-ID: <9210082047.AA01481@fnma.COM>
Date:	Thu, 8 Oct 1992 13:47:48 -0700
From:	s4uhkm@fnma.com (Howie Michalski)
Sender: sun330!fnma.COM!s4uhkm@uunet.uu.net
To:	seth%CAMP@onet.edu, MOO-Cows@parc.xerox.com,
	uunet!parc.xerox.com!Pavel@uunet.uu.net
Subject: Re: How about this for a built-in...


----- Begin Included Message -----

>From uunet!parc.xerox.com!pavel Thu Oct  8 14:11:04 1992
From: Pavel Curtis <uunet!parc.xerox.com!Pavel>
Sender: Pavel Curtis <uunet!parc.xerox.com!pavel>
Fake-Sender: pavel@parc.xerox.com
To: seth%CAMP@onet.edu, MOO-Cows@parc.xerox.com
Subject: Re: How about this for a built-in...
Date: 	Thu, 8 Oct 1992 10:33:30 PDT
Content-Length: 1405

>> Date:	Wed, 7 Oct 1992 14:40:27 -0700
>> From:	seth%CAMP@onet.edu (Seth I. Rich)
>> 
>> is there any reason why a get_task_info() shouldn't be a builtin?

>From: pavel@parc.xerox.com
>The principle of
>conceptual parsimony, therefore, argues against making it a built-in function.

----- End Included Message -----

I agree.  A function of this type seems best suited for a "standard" library.
One could even use C as a case in point; the stdio.h library contains, perhaps,
some of its most used functions - and, as with all libraries, can be written.
using built-ins.

Now, while we're on the subject of built-ins, how about something along the
lines of "you_know_where_Im_going_with_this_so_finish_it_off()" <grin>.  There
may be no difference in performance, but talk about significantly easier than
a primitive.


Cheers,
Howie





From phyvs0.anu.edu.au!dxb105 Thu Oct  8 18:57:12 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "8" "October" "1992" "18:57:05" "-0700" "David Bofinger" "dxb105@phyvs0.anu.edu.au" nil "17" "Re: How about this for a built-in..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29583>; Thu, 8 Oct 1992 18:56:56 -0700
Received: from phyvs0.anu.edu.au ([150.203.15.74]) by alpha.xerox.com with SMTP id <11650>; Thu, 8 Oct 1992 18:56:42 PDT
Received: by phys.anu.edu.au (MX V3.1) id 8705; Fri, 09 Oct 1992 11:57:29 +1000
Message-ID: <00961D52.66C049C0.8705@phys.anu.edu.au>
Date:	Thu, 8 Oct 1992 18:57:05 -0700
From:	David Bofinger <dxb105@phyvs0.anu.edu.au>
Sender: <dxb105@phyvs0.anu.edu.au>
To:	Pavel@parc.xerox.com
CC:	dxb105@phyvs0.anu.edu.au
Subject: Re: How about this for a built-in...

Pavel paraphrases:
>Is there any reason why get_task_info() *should* be a built-in?

The obvious answer is efficiency, given that MOO runs so much more slowly
than C it is reasonable to add a built-in to the server for anything that
is wasting a lot of CPU time.

I'd be mildly surprised if get_task_info() fell into this category, but who
knows. Does an easy method exist for deciding which library functionss have
been wasting CPU time? An interesting built-in would be one that returned
the CPU time consumed by the task so far -- is this worthwhile/possible/old
news?

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
------------------------------------------------------------------------------

From computing-maths.cardiff.ac.uk!Andrew.Wilson Fri Oct 16 06:23:50 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "16" "October" "1992" "05:44:59" "-0700" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "8" "The next LambdaCore..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Fri, 16 Oct 1992 06:23:47 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12019>; Fri, 16 Oct 1992 06:21:33 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12012>; Fri, 16 Oct 1992 06:18:30 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 16 Oct 1992 06:14:22 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12010>; Fri, 16 Oct 1992 06:13:50 PDT
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <12013>; Fri, 16 Oct 1992 06:13:19 PDT
Via: uk.ac.cardiff.computing-maths; Fri, 16 Oct 1992 13:46:02 +0100
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <23696-0@sentinel.cm.cf.ac.uk>; Fri, 16 Oct 1992 13:45:27 +0100
X-NS-Transport-ID: 08002008D0FD002E7B64
Message-ID: <9210161244.AA02597@jasper.cm.cf.ac.uk>
Date:	Fri, 16 Oct 1992 05:44:59 -0700
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	Moo-Cows.PARC@xerox.com
Subject: The next LambdaCore...


Hi,
	does anyone know if LambdaMOO @features are going to be in the
next release of the LambdaCore?  What else, that's new, will be included?
Has anyone got any entries for their LambdaCore wish-list?

Andy.


From xerox.com!PARC.xerox.com.PARC Sat Oct 17 15:23:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "17" "October" "1992" "15:08:51" "-0700" "Steven Charlton" "steven@cs.ualberta.ca" nil "9" "notify doesn't seem to work..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 17 Oct 1992 15:23:28 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12765>; Sat, 17 Oct 1992 15:22:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12758>; Sat, 17 Oct 1992 15:16:59 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 17 Oct 1992 15:10:04 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12753>; Sat, 17 Oct 1992 15:09:38 PDT
Received: from scapa.cs.ualberta.ca ([129.128.4.44]) by alpha.xerox.com with SMTP id <12756>; Sat, 17 Oct 1992 15:09:13 PDT
Received: from silver-vly.cs.ualberta.ca by scapa.cs.ualberta.ca id <42379-2>; Sat, 17 Oct 1992 16:08:59 -0600
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002E9253
XNS-Originator: PARC.xerox.com.PARC@Xerox.com
Errors-to: PARC.xerox.com.PARC@xerox.com
Message-ID: <92Oct17.160859mdt.42379-2@scapa.cs.ualberta.ca>
Date:	Sat, 17 Oct 1992 15:08:51 -0700
From:	Steven Charlton <steven@cs.ualberta.ca>
Sender: <@scapa.cs.ualberta.ca:steven@cs.ualberta.CA>
To:	Moo-Cows.PARC@xerox.com
Subject: notify doesn't seem to work...

I'm running the latest Moo and LambdaCore (not the new beta test version)
and I've run into a few problems.  Code that I've written and attached
to a player is unable to access other players .name property, and unable
to call notify to notify itself (the player) of something.  In both cases
I get a Permission denied message.

Any words of wisdom?

Steve

From nova.decio.nd.edu!jonathan Mon Oct 19 06:53:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "06:39:22" "-0700" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " nil "48" "VM_Allocate on NeXT driving me NUTS!" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 19 Oct 1992 06:53:55 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11688>; Mon, 19 Oct 1992 06:51:37 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11682>; Mon, 19 Oct 1992 06:47:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 19 Oct 1992 06:41:14 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11671>; Mon, 19 Oct 1992 06:40:47 PDT
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <11681>; Mon, 19 Oct 1992 06:40:24 PDT
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09608; Mon, 19 Oct 92 08:39:23 EST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002E9F96
Message-ID: <9210191339.AA09608@nova.decio.nd.edu>
Date:	Mon, 19 Oct 1992 06:39:22 -0700
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	MOO-Cows@xerox.com (Moo-Cows)
Subject: VM_Allocate on NeXT driving me NUTS!


I'm running the 1.6.11 server on a NeXT 68040 slab. It has 80MB drive 
free and a 20mb swap file. The server has a 1.2MB database. On both .11
and .1 after a period of time the server will panic with a
VM_ALLOCATE error from the system. This is generally after a memory
request is made and in this case, generally large although the size may
not be key. In all cases, the full database is never dumped causing me
to lose many hours (checkpointing is at 5am-6am).

The log shows:

Oct 14 20:44:16: #2: @d #17 (#17 is the help database in core)
memory allocation error: vm_allocate failed
memory allocation error: vm_allocate failed
memory allocation error: vm_allocate failed
Oct 14 20:44:25: *** PANIC: memory allocation (size 6164) failed!
Oct 14 20:44:57: *** PANIC: memory allocation (size 100) failed!
Oct 14 20:44:57: *** RECURSIVE PANIC: aborting

Last night, at 2am it crashed again. It saved about 1MB of the database.

The log shows:


Oct 19 02:02:49: #275: "I have the dates in your email.
Oct 19 02:03:02: #275: "Do youw ant to stay at my house, beginning, middle or end? do you need ride to/from airport?
Oct 19 02:03:14: #307: "Well, Myra ...
Oct 19 02:03:23: #307: "Why don't you just ask them if it's ok to stay for a night or two?
Oct 19 02:03:24: #275: "yeah Henry?
Oct 19 02:03:25: #307: "Think small.
Oct 19 02:03:30: #307: "I think that's the way to go.
Oct 19 02:03:34: #275: "Okey doke
Oct 19 02:03:50: #275: "I dont think it will matter to them if its beginning middle or end =)
Oct 19 02:03:51: *** PANIC: memory allocation (size 32768) failed!
Oct 19 02:03:51Oct 19 02:03:51: PANIC-DUMPING on dump.PANIC ...
memory allocation error: vm_allocate failed
Oct 19 02:04:14: *** PANIC: memory allocation (size 24) failed!
Oct 19 02:04:14: *** RECURSIVE PANIC: aborting

I would REALLY appreciate some help!!!!! What can I do to stop this? I
have been downing the system at 5am and bringing it back up but this
doesn't seem to have helped.

-- 
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -

From parc.xerox.com!pavel Mon Oct 19 10:38:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "10:22:45" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "19" "Re: notify doesn't seem to work..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 10:38:49 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11785>; Mon, 19 Oct 1992 10:36:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11760>; Mon, 19 Oct 1992 10:32:31 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 19 Oct 1992 10:25:42 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11758>; Mon, 19 Oct 1992 10:25:26 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11764>; Mon, 19 Oct 1992 10:23:07 PDT
Received: by lambda.parc.xerox.com id <58373>; Mon, 19 Oct 1992 10:22:54 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EA45E
In-Reply-to: <92Oct17.160859mdt.42379-2@scapa.cs.ualberta.ca>
Message-ID: <92Oct19.102254pdt.58373@lambda.parc.xerox.com>
References: <92Oct17.160859mdt.42379-2@scapa.cs.ualberta.ca>
Date:	Mon, 19 Oct 1992 10:22:45 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	steven@cs.ualberta.ca
cc:	Moo-Cows.PARC@xerox.com
Subject: Re: notify doesn't seem to work...

> Date:	Sat, 17 Oct 1992 15:08:51 -0700
> From:	Steven Charlton <steven@cs.ualberta.ca>
> 
> I'm running the latest Moo and LambdaCore (not the new beta test version)
> and I've run into a few problems.  Code that I've written and attached
> to a player is unable to access other players .name property, and unable
> to call notify to notify itself (the player) of something.  In both cases
> I get a Permission denied message.

This is very odd.  For the .name property, make absolutely sure that that's
what's causing the permissions error by trying a verb that ONLY reads the value
of the .name property of another player.  Reading that property on *any* valid
object should never cause a permissions error.

For the notify() primitive, are you certain that the owner of the verb is
either a wizard or else exactly the same as the player to whom you're trying to
print something?

	Pavel/Haakon

From parc.xerox.com!pavel Mon Oct 19 10:49:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "10:31:01" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "33" "Re: VM_Allocate on NeXT driving me NUTS!" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 10:49:49 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11768>; Mon, 19 Oct 1992 10:47:54 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11777>; Mon, 19 Oct 1992 10:44:59 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Mon, 19 Oct 1992 10:38:19 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11759>; Mon, 19 Oct 1992 10:37:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11763>; Mon, 19 Oct 1992 10:32:38 PDT
Received: by lambda.parc.xerox.com id <58374>; Mon, 19 Oct 1992 10:32:33 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EA494
In-Reply-to: <9210191339.AA09608@nova.decio.nd.edu>
Message-ID: <92Oct19.103233pdt.58374@lambda.parc.xerox.com>
References: <9210191339.AA09608@nova.decio.nd.edu>
Date:	Mon, 19 Oct 1992 10:31:01 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	jonathan@nova.decio.nd.edu
cc:	Moo-Cows.PARC@xerox.com
Subject: Re: VM_Allocate on NeXT driving me NUTS!

> Date:	Mon, 19 Oct 1992 06:39:22 -0700
> From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
> 
> I'm running the 1.6.11 server on a NeXT 68040 slab. It has 80MB drive 
> free and a 20mb swap file. The server has a 1.2MB database. On both .11
> and .1 after a period of time the server will panic with a
> VM_ALLOCATE error from the system. This is generally after a memory
> request is made and in this case, generally large although the size may
> not be key. In all cases, the full database is never dumped causing me
> to lose many hours (checkpointing is at 5am-6am).

First, I strongly recommend checkpointing *much* more frequently than once per
day if you can possibly afford it.

Second, to track down the memory problem, I would run the server under a
debugger, setting a breakpoint in `panic' (and also telling the debugger not to
stop when the server receives a SIGPIPE signal).  When the server next gets the
memory error, use `ps' to see how much memory it's using.  Also, you could try
using `pstat -s' before you start up the server to get an idea of just how much
swap space is left over for the server.  20 megabytes is not a great deal of
swap space for everything running on a NeXT machine to share; I wouldn't be
surprised if there was only 5 megabytes or so leftover for the server, and
that's certainly not enough.

This overall problem, of the server panicking when it runs out of memory, is
the single most severe robustness problem; unfortunately, I have not been able
to come up with any good ways to solve the problem in the current server.  It
is easier to see how one might solve it in the disk-based server, so perhaps
I'll be able to get such a fix in before that's released.

Until then, I'm sorry; you're just going to have to give it more space.

	Pavel

From cheetah.math.oxy.edu!t_pascal Mon Oct 19 12:39:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "12:26:54" "-0700" "C. Regis Wilson" "t_pascal@cheetah.math.oxy.edu " nil "30" "Re: VM_Allocate on NeXT driving me NUTS!" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 12:38:56 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11820>; Mon, 19 Oct 1992 12:35:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11798>; Mon, 19 Oct 1992 12:34:22 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Mon, 19 Oct 1992 12:28:03 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11773>; Mon, 19 Oct 1992 12:27:34 PDT
Received: from cheetah.math.oxy.edu ([134.69.1.18]) by alpha.xerox.com with SMTP id <11796>; Mon, 19 Oct 1992 12:27:07 PDT
Received: by cheetah.math.oxy.edu (Sendmail5.52/NeXT-2.0)
	id AA03065; Mon, 19 Oct 92 12:26:54 PDT
Received: by NeXT Mailer (1.63)
X-NS-Transport-ID: 08002008D0FD002EA724
Message-ID: <9210191926.AA03065@cheetah.math.oxy.edu>
Date:	Mon, 19 Oct 1992 12:26:54 -0700
From:	t_pascal@cheetah.math.oxy.edu (C. Regis Wilson)
To:	Moo-Cows.PARC@xerox.com
Subject: Re: VM_Allocate on NeXT driving me NUTS!

>I'm running the 1.6.11 server on a NeXT 68040 slab. It has 80MB drive 

>free and a 20mb swap file. The server has a 1.2MB database. On both .11
>and .1 after a period of time the server will panic with a
>VM_ALLOCATE error from the system. This is generally after a memory
>request is made and in this case, generally large although the size may
>not be key. In all cases, the full database is never dumped causing me
>to lose many hours (checkpointing is at 5am-6am).
>
I have also been plagued with this problem.  I've tried lots of things,
and I think it can be solved by setting the hiwat variable in
/etc/swaptab.  Perhaps, if the variable is not set, it defaults to a
small value?  Setting it to 0 will allow you as much vm as you have space
on disk.  Here is my swaptab.  However, an 80Mb drive may not be enough. 


#
#	/etc/swaptab
#
/private/vm/swapfile	lowat=20000000	hiwat=60000000


---

---------
T. Pascal, King of Pascal          | "He travels fastest who travels alone,
1600 Campus Road, Box 829          | but not when the frost drops below zero
Los Angeles, CA 90041              | fifty degrees or more."
                                   |         -Old eskimo saying
       t_pascal@{{{cub,cheetah,jaguar}.math},tiger,cheshire}.oxy.edu

From uunet.uu.net!cbmvax!lynx!davidm Mon Oct 19 18:43:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "17:06:10" "-0700" "David Miller" "cbmvax!lynx!davidm@uunet.uu.net" "<719539572.AA7001@lynx.cbm.commodore.com>" "20" "Re: VM_Allocate on NeXT driving me NUTS!" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 18:43:34 -0700
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <11965>; Mon, 19 Oct 1992 18:43:15 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA18013; Mon, 19 Oct 92 21:43:13 -0400
Received: from cbmvax.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 214215.14720; Mon, 19 Oct 1992 21:42:15 EDT
Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore 2/8/91)
	id AA25558; Mon, 19 Oct 92 20:10:39 EDT
In-Reply-To: <92Oct19.103233pdt.58374@lambda.parc.xerox.com>; from "Pavel Curtis" at Oct 19, 92 10:31 am
X-Mailer: ELM [version 2.3 PL11 913261353]
Message-Id: <719539572.AA7001@lynx.cbm.commodore.com>
Content-Type: text
Content-Length: 864
Date:	Mon, 19 Oct 1992 17:06:10 -0700
From:	David Miller <cbmvax!lynx!davidm@uunet.uu.net>
To:	Pavel@parc.xerox.com (Pavel Curtis)
Cc:	jonathan@nova.decio.nd.edu, moo-cows.parc@xerox.com
Subject: Re: VM_Allocate on NeXT driving me NUTS!
Reply-To: cbmvax!lynx!davidm@uunet.uu.net

|This overall problem, of the server panicking when it runs out of memory, is
|the single most severe robustness problem; unfortunately, I have not been able
|to come up with any good ways to solve the problem in the current server.  It
|is easier to see how one might solve it in the disk-based server, so perhaps
|I'll be able to get such a fix in before that's released.
|
|Until then, I'm sorry; you're just going to have to give it more space.
|
|	Pavel

There is a work around for this sort of problem.  When you start up,
allocate as much memory as you will need to do a dump should a panic
occur.  When an out-of-memory panic occurs, free the saved memory and
proceed with the shutdown.  

DavidM
-- 
DavidM			CATS - Commodore Applications and Technical Support
+1 215 431 9425		davidm@cbmvax.commodore.com
"Commodore Amiga 3000UX - Born to Run UNIX SVR4"

From parc.xerox.com!pavel Mon Oct 19 19:24:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "19:03:38" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "20" "Re: VM_Allocate on NeXT driving me NUTS!" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 19:24:36 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11980>; Mon, 19 Oct 1992 19:23:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11972>; Mon, 19 Oct 1992 19:22:11 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58379>; Mon, 19 Oct 1992 19:05:45 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11979>; Mon, 19 Oct 1992 19:04:35 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11974>; Mon, 19 Oct 1992 19:03:57 PDT
Received: by lambda.parc.xerox.com id <58379>; Mon, 19 Oct 1992 19:03:41 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EAEA9
In-Reply-to: <719539572.AA7001@lynx.cbm.commodore.com>
Message-ID: <92Oct19.190341pdt.58379@lambda.parc.xerox.com>
References: <719539572.AA7001@lynx.cbm.commodore.com>
	<92Oct19.103233pdt.58374@lambda.parc.xerox.com>
Date:	Mon, 19 Oct 1992 19:03:38 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	cbmvax!lynx!davidm@uunet.uu.net
cc:	moo-cows.parc@xerox.com
Subject: Re: VM_Allocate on NeXT driving me NUTS!

> Date:	Mon, 19 Oct 1992 17:06:10 -0700
> From:	David Miller <cbmvax!lynx!davidm@uunet.uu.net>
> 
> There is a work around for this sort of problem.  When you start up,
> allocate as much memory as you will need to do a dump should a panic
> occur.  When an out-of-memory panic occurs, free the saved memory and
> proceed with the shutdown.  

This isn't guaranteed to work, though it does improve your chances.  The
problem is that some allocators never split an large freed objects when you ask
for smaller ones, and some allocators never coalesce small freed objects when
you ask for larger ones.  Thus, you could free up all that nice storage you
saved away and then find that malloc() still returns 0 because the memory you
freed isn't in the right size chunks.

The more difficult problem, in any case, is avoiding the out-of-memory panic in
the first place.  This is the problem that I think I may be able to solve in
the disk-based server, but not in the memory-based one.

	Pavel

From casbah.acns.nwu.edu!hpa Mon Oct 19 19:29:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "19:29:09" "-0700" "H. Peter Anvin N9ITP" "hpa@casbah.acns.nwu.edu " "<9210200229.AA13120@casbah.acns.nwu.edu>" "14" "Diskbased vs. memory based server" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 19:29:36 -0700
Received: from casbah.acns.nwu.edu ([129.105.113.52]) by alpha.xerox.com with SMTP id <11992>; Mon, 19 Oct 1992 19:29:18 PDT
Received: by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA13120; Mon, 19 Oct 92 21:29:12 CDT
Message-Id: <9210200229.AA13120@casbah.acns.nwu.edu>
In-Reply-To: <92Oct19.190341pdt.58379@lambda.parc.xerox.com>; from "Pavel Curtis" at Oct 19, 92 7:03 pm
X-Mailer: ELM [version 2.3 PL11]
Date:	Mon, 19 Oct 1992 19:29:09 -0700
From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
To:	Pavel@parc.xerox.com (Pavel Curtis)
Cc:	moo-cows@parc.xerox.com (MOO-Cows Mailing List)
Subject: Diskbased vs. memory based server
Reply-To: hpa@nwu.edu

You write:
> the first place.  This is the problem that I think I may be able to solve in
> the disk-based server, but not in the memory-based one.

Just outof curiosity (don't take this the wrong way, please); but is there
an update on the progress of the diskbased server?  

	/hpa

-- 
INTERNET:  hpa@nwu.edu   TALK:      hpa@casbah.acns.nwu.edu
BITNET:    HPA@NUACC     IBMNET:    16331@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  hpa@lenny.acns.nwu.edu
rm -rf /msdos /windows /nt

From parc.xerox.com!pavel Mon Oct 19 19:53:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "19:42:13" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "31" "Re: Diskbased vs. memory based server" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 19:53:22 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11995>; Mon, 19 Oct 1992 19:52:14 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11971>; Mon, 19 Oct 1992 19:49:48 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58381>; Mon, 19 Oct 1992 19:43:07 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11971>; Mon, 19 Oct 1992 19:42:39 PDT
Received: by lambda.parc.xerox.com id <58381>; Mon, 19 Oct 1992 19:42:25 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EAF2E
In-Reply-to: <9210200229.AA13120@casbah.acns.nwu.edu>
Message-ID: <92Oct19.194225pdt.58381@lambda.parc.xerox.com>
References: <9210200229.AA13120@casbah.acns.nwu.edu>
	<92Oct19.190341pdt.58379@lambda.parc.xerox.com>
Date:	Mon, 19 Oct 1992 19:42:13 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	hpa@nwu.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: Diskbased vs. memory based server

> Date:	Mon, 19 Oct 1992 19:29:09 -0700
> From:	hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP)
> 
> Just out of curiosity (don't take this the wrong way, please); but is there
> an update on the progress of the diskbased server?  

I intend to begin real work on the disk-based server sometime in the first week
of November.  Much of the design work is already done and I am already in the
process of getting the low-level database management code from researchers at
UC Berkeley.  This code, for those who understand this sort of thing, provides
an essentially DBM-like interface but uses log-based recovery techniques to
ensure transaction semantics.  [Translation: the server won't lose data when it
crashes...]

I don't know how long it will take me to finish the conversion of the server.
On the one hand, the code has already been split along the proper boundary to
be ready for swapping in a new DB representation.  On the other hand, I am also
going to be trying to work on the Jupiter (multi-media MOO) project here at
PARC, getting the first version of `easy portable window-based interfaces to
MOO objects' up and running.  (Look for a public release of the Jupiter window
system code, both in-database MOO-code and a special client program, sometime
in the first half of the new year...)

It's quite possible that I will give the Jupiter project priority over
disk-basing for much of the month of November, but I haven't decided about that
yet.  Even if I do, I would expect that we'll be testing the disk-based server
on LambdaMOO itself by mid-December, with public release by sometime around New
Year's Day.  It might come sooner, it might come later, but this is my current
best guess.

	Pavel

From seagull.sky.tucson.az.us!web Mon Oct 19 20:08:49 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "19:53:13" "-0700" "Wayne E. Bouchard" "web@seagull.sky.tucson.az.us " nil "4" "Suggestion." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 20:08:39 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12002>; Mon, 19 Oct 1992 20:07:38 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11995>; Mon, 19 Oct 1992 20:06:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58382>; Mon, 19 Oct 1992 19:57:47 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11992>; Mon, 19 Oct 1992 19:57:17 PDT
Received: from Arizona.edu ([128.196.128.232]) by alpha.xerox.com with SMTP id <11992>; Mon, 19 Oct 1992 19:56:30 PDT
Received: from seagull.sky.tucson.az.us by Arizona.edu (PMDF #2381 ) id
 <01GQ588Q8IO08ZG9C4@Arizona.edu>; Mon, 19 Oct 1992 19:56:13 MST
Received: by seagull.sky.tucson.az.us (4.1/SMI-4.1) id AA18727; Mon,
 19 Oct 92 19:53:15 MST
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002EAF41
Message-ID: <9210200253.AA18727@seagull.sky.tucson.az.us>
Date:	Mon, 19 Oct 1992 19:53:13 -0700
From:	web@seagull.sky.tucson.az.us (Wayne E. Bouchard)
To:	MOO-Cows.parc@xerox.com
Subject: Suggestion.

   Unless I've missed it, I would like to see @chown made into a
builtin. [chown(<object>, <new-owner>)]. I seem to remember people
telling me that this would tend to simplify things a bit for them.
/shrug just a thought.

From cs.stanford.edu!crew Mon Oct 19 21:21:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "21:12:25" "-0700" "Roger Crew" "crew@cs.stanford.edu" nil "27" "Re: Suggestion." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 21:20:57 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12026>; Mon, 19 Oct 1992 21:19:56 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12021>; Mon, 19 Oct 1992 21:17:55 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58383>; Mon, 19 Oct 1992 21:12:42 -0700
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <12017>; Mon, 19 Oct 1992 21:12:24 PDT
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA23994; Mon, 19 Oct 92 21:12:26 PDT
X-NS-Transport-ID: 08002008D0FD002EAFFF
In-Reply-to: "Your message of \"Mon, 19 Oct 92 19:53:13 PDT.\"
             <9210200253.AA18727@seagull.sky.tucson.az.us>, how"
Message-ID: <9210200412.AA23994@Xenon.Stanford.EDU>
Date:	Mon, 19 Oct 1992 21:12:25 -0700
From:	Roger Crew <crew@cs.stanford.edu>
To:	MOO-Cows@parc.xerox.com
Subject: Re: Suggestion.

web@seagull.sky.tucson.az.us (Wayne E. Bouchard) writes:
> Unless I've missed it, I would like to see @chown made into a builtin. 

In effect, it already is a builtin, albeit with strange syntax, i.e., 

    (foo.owner = newowner);

rather than 

    chown(foo,newowner);

The problem is that this doesn't do quite what one wants.  Simply changing 
the owner field doesn't suffice, given the way property permissions are 
currently handled.  In particular, this should automatically change the 
ownership on all of the object's +c properties, but it doesn't.  

The most recent release of LambdaCore provides 

    $wiz_utils:set_owner(foo,newowner)

which is probably what you want to use for now.  Since there are arguments
about exactly how +c properties should work anyway, the real solution
hangs on the question of what should be (is going to be) done about them.
--
Roger Crew
Internet:  crew@CS.Stanford.EDU
LambdaMOO:  Rog

From wvnvaxa.wvnet.edu!UN032233 Mon Oct 19 21:25:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "19" "October" "1992" "21:15:25" "-0700" "Gilmore" "UN032233@wvnvaxa.wvnet.edu" nil "7" "Built-in functions" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 19 Oct 1992 21:25:42 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12024>; Mon, 19 Oct 1992 21:23:58 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12026>; Mon, 19 Oct 1992 21:22:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58384>; Mon, 19 Oct 1992 21:17:56 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12013>; Mon, 19 Oct 1992 21:16:35 PDT
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12024>; Mon, 19 Oct 1992 21:16:08 PDT
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQ5H733I1S9TCUW5@WVNVMS.WVNET.EDU>; Tue, 20 Oct 1992 00:15:25 EDT
X-VMS-To: IN%"moo-cows.parc@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002EAFFE
Message-ID: <01GQ5H733ROY9TCUW5@WVNVMS.WVNET.EDU>
Date:	Mon, 19 Oct 1992 21:15:25 -0700
From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
To:	moo-cows.parc@xerox.com
Subject: Built-in functions

As long as we're talking about a wish-list of built in functions, there's
one I've rather wanted to see for a while: isa(object, class) - basically
the same functionality as the $object_utils:isa() verb.  It's just that I 
can't count the number of times I've used this, and it seems like it would
save a lot of ticks.  *shrug*  I agree with the chown() idea, also.

Gilmore

From wvnvaxa.wvnet.edu!UN032233 Tue Oct 20 08:51:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "20" "October" "1992" "08:38:25" "-0700" "Gilmore" "UN032233@wvnvaxa.wvnet.edu" nil "11" "Quick question" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 20 Oct 1992 08:51:45 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12166>; Tue, 20 Oct 1992 08:51:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12230>; Tue, 20 Oct 1992 08:46:40 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58386>; Tue, 20 Oct 1992 08:39:51 -0700
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12218>; Tue, 20 Oct 1992 08:39:13 PDT
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQ652OI9LS9TCYF2@WVNVMS.WVNET.EDU>; Tue, 20 Oct 1992 11:38:25 EDT
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002EB6FD
Message-ID: <01GQ652OIJ8Y9TCYF2@WVNVMS.WVNET.EDU>
Date:	Tue, 20 Oct 1992 08:38:25 -0700
From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
To:	moo-cows@parc.xerox.com
Subject: Quick question

Just out of curiosity ...

Which is more efficient?

(1)  list = {@list, item};
(2)  list = listappend(list, item);

By efficient, I mean from a standpoint of actual CPU time to perform the
operation.

                    - Gilmore

From stony-brook.scrc.symbolics.com!yduJ Tue Oct 20 09:00:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "20" "October" "1992" "08:56:00" "-0700" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "16" "Quick question" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 20 Oct 1992 09:00:32 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12245>; Tue, 20 Oct 1992 08:59:52 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12228>; Tue, 20 Oct 1992 08:57:31 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58388>; Tue, 20 Oct 1992 08:53:14 -0700
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11768>; Tue, 20 Oct 1992 08:53:05 PDT
Received: from AVOCADO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1160922; 20 Oct 1992 11:52:25-0400
X-NS-Transport-ID: 08002008D0FD002EB730
In-Reply-to: <01GQ652OIJ8Y9TCYF2@WVNVMS.WVNET.EDU>
Message-ID: <19921020155647.1.YDUJ@AVOCADO.SCRC.Symbolics.COM>
Date:	Tue, 20 Oct 1992 08:56:00 -0700
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	UN032233@wvnvaxa.wvnet.edu, moo-cows@parc.xerox.com
Subject: Quick question

    Date: Tue, 20 Oct 1992 11:38 EDT
    From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>

    Just out of curiosity ...

    Which is more efficient?

    (1)  list = {@list, item};
    (2)  list = listappend(list, item);

    By efficient, I mean from a standpoint of actual CPU time to perform the
    operation.

			- Gilmore

These are equivalent.

From parc.xerox.com!pavel Tue Oct 20 11:13:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "20" "October" "1992" "11:04:50" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "20" "Re: Quick question" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 20 Oct 1992 11:13:41 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12251>; Tue, 20 Oct 1992 11:13:22 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12263>; Tue, 20 Oct 1992 11:10:15 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58390>; Tue, 20 Oct 1992 11:05:25 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12269>; Tue, 20 Oct 1992 11:05:02 PDT
Received: by lambda.parc.xerox.com id <58390>; Tue, 20 Oct 1992 11:04:51 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EBA73
In-Reply-to: <01GQ652OIJ8Y9TCYF2@WVNVMS.WVNET.EDU>
Message-ID: <92Oct20.110451pdt.58390@lambda.parc.xerox.com>
References: <01GQ652OIJ8Y9TCYF2@WVNVMS.WVNET.EDU>
Date:	Tue, 20 Oct 1992 11:04:50 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	UN032233@wvnvaxa.wvnet.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: Quick question

> Date:	Tue, 20 Oct 1992 08:38:25 -0700
> From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
> 
> Which is more efficient?
> 
> (1)  list = {@list, item};
> (2)  list = listappend(list, item);
> 
> By efficient, I mean from a standpoint of actual CPU time to perform the
> operation.

In terms of either ticks or real CPU time, the first one is a *little* bit
cheaper.  The major difference is that the second one must first construct the
list {list, item} in order to call the built-in function, while the first one
only does the actual result-list computation.

That the first one is also easier to understand and is thus more likely to
attract my optimization attention in the future is, of course, gravy.

	Pavel

From suna0.cs.uiuc.edu!scott Tue Oct 20 18:39:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "20" "October" "1992" "18:30:49" "-0700" "Jay Scott" "scott@suna0.cs.uiuc.edu" "<199210210130.AA04600@sparc7.cs.uiuc.edu>" "16" "LambdaMOO lag" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 20 Oct 1992 18:39:35 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12391>; Tue, 20 Oct 1992 18:39:01 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12395>; Tue, 20 Oct 1992 18:35:59 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58394>; Tue, 20 Oct 1992 18:30:03 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12397>; Tue, 20 Oct 1992 18:29:19 PDT
Received: from sparc7.cs.uiuc.edu ([128.174.244.117]) by alpha.xerox.com with SMTP id <12396>; Tue, 20 Oct 1992 18:28:42 PDT
Received: by sparc7.cs.uiuc.edu id AA04600
  (5.65c/IDA-1.4.4 for moo-cows@xerox.com); Tue, 20 Oct 1992 20:30:49 -0500
X-NS-Transport-ID: 08002008D0FD002EC39D
Message-ID: <199210210130.AA04600@sparc7.cs.uiuc.edu>
Date:	Tue, 20 Oct 1992 18:30:49 -0700
From:	Jay Scott <scott@suna0.cs.uiuc.edu>
To:	moo-cows.PARC@xerox.com
Subject: LambdaMOO lag

The server has been rewritten, and now it is much faster.
When LambdaMOO switched to the new server, lag went way down.
But now lag has climbed again and it is as bad as it ever was.
Yesterday the lag meter sampled one lag that was over ten minutes.

Way back when, Pavel said that the big cause of server lag
on LambdaMOO was background tasks. If this is still true,
then people must be running more background tasks than they
they used to, or more expensive ones.

Is that true? Did people say 'Hey, this is much better, I can
afford some more spam for the fridge now'? Or is Pavel just
using his machine more heavily? :-)

	Curious Frand
	scott@cs.uiuc.edu

From parc.xerox.com!pavel Tue Oct 20 20:06:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "20" "October" "1992" "19:55:49" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "21" "Re: LambdaMOO lag" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 20 Oct 1992 20:05:55 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12415>; Tue, 20 Oct 1992 20:05:01 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12414>; Tue, 20 Oct 1992 20:03:08 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58395>; Tue, 20 Oct 1992 19:57:06 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12407>; Tue, 20 Oct 1992 19:56:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12411>; Tue, 20 Oct 1992 19:56:14 PDT
Received: by lambda.parc.xerox.com id <58395>; Tue, 20 Oct 1992 19:56:00 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EC482
In-Reply-to: <199210210130.AA04600@sparc7.cs.uiuc.edu>
Message-ID: <92Oct20.195600pdt.58395@lambda.parc.xerox.com>
References: <199210210130.AA04600@sparc7.cs.uiuc.edu>
Date:	Tue, 20 Oct 1992 19:55:49 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	scott@suna0.cs.uiuc.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: LambdaMOO lag

> Date:	Tue, 20 Oct 1992 18:30:49 -0700
> From:	Jay Scott <scott@suna0.cs.uiuc.edu>
> 
> But now lag has climbed again and it is as bad as it ever was.
> 
> Way back when, Pavel said that the big cause of server lag
> on LambdaMOO was background tasks. If this is still true,
> then people must be running more background tasks than they
> they used to, or more expensive ones.
> 
> Is that true? Did people say 'Hey, this is much better, I can
> afford some more spam for the fridge now'? Or is Pavel just
> using his machine more heavily? :-)

I have, in fact, been using my machine somewhat more heavily at times, but I
think that the real cause of the lag is increased usage of background tasks.  I
am likely to be given a second workstation pretty soon, so that I can dedicate
`lambda' to running the MOO.  This will probably help the lag a little and my
sanity a lot... :-)

	Pavel/Haakon

From parc.xerox.com!pavel Tue Oct 20 20:44:23 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "20" "October" "1992" "20:36:27" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "136" "Gamma-testing LambdaMOO release 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Tue, 20 Oct 1992 20:44:14 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12420>; Tue, 20 Oct 1992 20:43:28 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12422>; Tue, 20 Oct 1992 20:41:56 PDT
Received: by lambda.parc.xerox.com id <58397>; Tue, 20 Oct 1992 20:36:37 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002EC4E1
Message-ID: <92Oct20.203637pdt.58397@lambda.parc.xerox.com>
Date:	Tue, 20 Oct 1992 20:36:27 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Gamma-testing LambdaMOO release 1.7.0
Reply-to: Pavel@parc.xerox.com

Yes, I know you're supposed to stop at beta-testing, but I'm afraid we need to
do one more iteration.  I'm hoping that it will go more quickly this time; the
distribution now includes a nifty automatic configuration shell script, so that
you should only need to run the script and then type `make' to get it going on
your machine.

If you're going to participate in the gamma-test, *please* do so and send me
the results by Wednesday evening.  I *really* want to get the release out on
Thursday if at all possible.

Here's the testing procedure, slightly modified from last time:

Because this server incorporates a number of new networking implementations to
enable the server's use on a broader array of platforms (including single- and
multi-user use on machines without a network), it made sense to me that we
should do one quick run-through of volunteers trying to get the system up and
running on as many kind of machines as possible, using as many networking
implementations as possible.  It should be possible to get it running in at
least some configuration on any UNIX machine, and perhaps without too much
trouble on other POSIX-compliant platforms.  None of the configurations in this
release will work on an MS/DOS machine.

Here's what I'd like a bunch of you to do for me (I *strongly* recommend that
you read this all the way through before starting):

1) Reply to this message (making sure that the reply is going to me only, not
   the whole MOO-Cows list) telling me the kind of hardware and operating
   system you're willing to test the server on.  I'll let you know if someone
   else is already doing that configuration, so that we avoid uselessly
   duplicating work.  If you don't hear back from me, assume that you're the
   one person testing that configuration and go for it.

2) FTP the distribution from host `parcftp.xerox.com', directory `pub/MOO',
   file `LambdaMOO-gamma.tar.Z'; don't forget to use binary mode.  Also, using
   `ascii' mode, fetch `LambdaCore-12Aug92.db', renaming it to `LambdaCore.db'
   on your machine.  Unpack the compressed tar file in a clean directory.

3) Start some email to me, including the following information:
	Hardware type: >>Sun 3, SPARCstation, SGI, DECstation, etc.<<
	Operating System: >>SunOS 4.1.1, IRIX 3.3.3, Ultrix 4.2, etc.<<
	Compiler: >>Vendor supplied, GCC, etc.<<

4) Following the directions in the release, try to compile it first for the
   NP_SINGLE networking option.  NOTE: the compilation instructions have
   changed in this release, so please do reread them.  Make a note or, much
   better, keep a verbatim copy of any warnings or errors you get from your
   compiler.  If it doesn't compile properly, see if you can figure out what I
   need to change in the code to make it do so.  If you can't figure it out,
   don't sweat it; I'll try to figure it out for myself.  Remember, the goal is
   that the server compile on your machine with *no* warnings or errors (except
   maybe for some in /usr/lib/yaccpar, which I don't control).

5) Add to your email message to me the copy you made of the warnings and/or
   errors you got in step 4, along with a description (preferably in diff -c
   format) of any changes you did to make it work.

6) If you couldn't get the NP_SINGLE option to compile, stop here and send me
   that email message.  With luck, I'll be able to get you over this hump and
   you can then continue.

7) If you *did* get the NP_SINGLE option to compile, try running it:

	./moo LambdaCore.db foo.db

   After loading the database, it should `connect' you to the server using the
   normal input and output streams of the server itself.  Type `co wizard' to
   log in and then `news' to make sure that commands work.  Then type `@quit'.
   You should be `disconnected' and then immediately `reconnected', getting the
   welcoming banner again.  This time don't log in but instead hit Ctrl-C (or
   whatever your usual `interrupt' key is); the server should go through its
   normal shutdown procedure, dumping the database into `foo.db'.

   If all this works normally, add something like this line to your message:

	Option NP_SINGLE passed the test.

   If it didn't work, then please describe in your message, as carefully as
   possible, what happened instead.  Then stop, sending that message off to me.

8) If you're still going, then it's time to test out each of the multi-user
   configurations in turn.  Edit `options.h' to change the definitions of
   NETWORK_PROTOCOL and NETWOK_STYLE.  Add to your message a description of
   which one you're trying.  Following the directions in the release, compile
   the server again.

9) As before, add to your message a copy of any warnings or errors you get, and
   try to make them go away, telling me what you did if you succeed.  If you
   can't get it to compile without errors, then give up on this configuration
   and go back to step 8 to try another one.

10) If you're here, then you've gotten some multi-user configuration to compile
   and you're ready to test it.  You will need three windows or terminals to do
   this properly.  In window 1, start the server:

	./moo LambdaCore.db foo.db

   In window 2, start a client for that server; if you're using the NP_LOCAL
   value of NETWORK_PROTOCOL, then use either `client_bsd' or `client_sysv', as
   appropriate.  Otherwise, use `telnet localhost 7777'.

   When you're connected in window 2, type `co wizard' to log in, and `news' to
   test whether normal commands work.  Then start a client in window 3; when
   connected, type `cr foo foo' to create a new character, `news' to test
   commands in that window, and `@quit' to disconnect.  There should be `foo
   has connected' and `foo has disconnected' messages in window 2.  Back in
   window 2, type `;shutdown("")' to shut down the server.  It should shut down
   normally, dumping the database into `foo.db'.

11) If all this worked fine, add a line to your message like this:

	Option NP_whatever/NS_whatever passed the test.

   If it didn't work right, then please add a careful description of what went
   wrong.

12) Repeat steps 8-11 for each of the four possible combinations of NP_* and
   NS_*.  Don't worry if some of them fail even to compile; so far, only SunOS
   has managed to make all of them work (unsurprising, since that's where I
   developed them).  When you've tested everything you can, and included in
   your message every warning, error, and failed test, send off that email to
   me.

By myself, I have already tested the server on the following platforms:

	SPARCstation running SunOS 4.1.1 (GCC)
	SPARCstation running Solaris 2.0 (vendor compiler)
	NeXT machine running NeXT Mach (vendor compiler == GCC)
	IBM RS/6000 running AIX version 3 (vendor compiler)

I will be testing on SPARCstations running SunOS 4.1.2 and 4.1.3 (GCC) as well.
Everything else is up for grabs!

I thank you all very much in advance for helping make LambdaMOO easy for lots
of other people to bring up on their machines.

	Pavel/Haakon

From parc.xerox.com!pavel Fri Oct 23 17:01:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "23" "October" "1992" "16:48:20" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "123" "LambdaMOO Server Release 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29594>; Fri, 23 Oct 1992 17:01:10 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12311>; Fri, 23 Oct 1992 16:59:25 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12303>; Fri, 23 Oct 1992 16:55:54 PDT
Received: by lambda.parc.xerox.com id <58372>; Fri, 23 Oct 1992 16:48:29 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F00D6
Message-ID: <92Oct23.164829pdt.58372@lambda.parc.xerox.com>
Date:	Fri, 23 Oct 1992 16:48:20 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: LambdaMOO Server Release 1.7.0

At long last, I have finally gotten the server sufficiently in shape to allow
the release of version 1.7.0, which is now available for anonymous FTP from
host `parcftp.xerox.com', directory `pub/MOO', file `LambdaMOO-1.7.0.tar.Z'.

There are many changes and improvements over the last release 1.6.1; I have
enclosed the relevant portion of the change log below.

NOTE that there are some *incompatible* changes in this release; the change log
(ChangeLog.txt in the release) describes the changes and semi-automatic methods
for converting existing databases.

This release of the server is believed to be relatively straightforward to use
on *any* UNIX system, and should automatically configure itself to cope with
the eccentricities of each individual one.  Naturally, this broad claim is
surely wrong, so please let me know of failures and I'll do what I can to make
things better.

The 1.7.0 version of the LambdaMOO Programmer's Manual, and a brand-new version
of the LambdaCore database, will be released tomorrow (barring disaster).

	Pavel/Haakon

>From ChangeLog.txt:

Version 1.7.0, 23 October 1992
-- Fixed behavior of index(), rindex(), match(), and rmatch() on empty pattern
   and/or subject strings. (Version 1.6.3)
-- Added the prefix `> ' to all log messages generated by the server_log()
   built-in function, so that they can be distinguished from server-generated
   messages.
-- Added a compile-time option (OUT_OF_BAND_PREFIX) enabling a method of
   entering commands that bypass both normal command parsing and any pending
   read()ing task.  If OUT_OF_BAND_PREFIX is #define'd (in config.h) as a
   non-empty string, then any lines of player input that begin with that prefix
   will be parsed into a list of words and those words passed as arguments in a
   server task invoking #0:do_out_of_band_command.  This is intended for use by
   fancy MOO clients that need to send reliably-understood messages to the
   server, such as window-event notifications.
-- Added output to the `.program' built-in command, stating that it is obsolete
   and will be replaced `soon' (i.e., in the next release).
-- Rearranged the per-system configuration procedure for compiling the server;
   now it should be easier for people to understand just what needs to be done
   for their particular system.  The user changes in the Makefile are now
   confined to specfying details of the compiler; all other kinds of options
   are handled by editing the `config.h' file, which has been radically
   reorganized.
-- Renamed a few files (notably parse_command.[ch]) to fit within the
   14-character limit imposed on certain systems.  (Version 1.6.4)
-- Implemented reference counting on string and list values, replacing the old,
   CPU-intensive deep copying method of storage management.
-- Added subrange assignment for strings and lists.  Added indexed assignment
   for strings.  (Version 1.6.5)
-- Fixed bug whereby a read()ing task with no more input to consume was never
   resumed if the connection being read was subsequently closed, from either
   side.  Now the read() call raises E_INVARG, just as it would if the read()
   were begun when the connection was already closed and no more input was left
   to consume.
-- Added TYPE_CLEAR value to properties, which cause property lookup on the
   parent.  Added built in functions `clear_property()' and
   `is_clear_property()' to assist in TYPE_CLEAR property manipulation.
-- Added hash-lookup for properties and changed property definition
   representation to be arrays instead of linked-lists, both to speed up
   property lookup. (1.6.6)
-- Added support for multiple complete networking implementations.  The first
   use of this flexibility is a new SINGLE_USER option, which creates a version
   of the server that accepts only one connection at a time and uses the
   server's own standard input and output streams for it.
-- Added a new built-in property on objects, the `f' (for `fertile') bit; it
   replaces the use of the `r' bit to allow children to be made of the object
   by either create() or chparent().  That is, now those operations check that
   the `f' bit is set and disregard the setting of the `r' bit. (Version 1.6.7)
   ******** Before upgrading an existing MOO to use this version of the server,
   * NOTE * you should make sure that no object in your database already has a
   ******** property named `f'; the following MOO program, run by a wizard,
   will perform this check:
		for i in [0..tonum(max_object())]
		  o = toobj(i);
		  if (ticks_left() < 1000 || seconds_left() < 2)
		    notify(player, tostr("Checking ", o, " ..."));
		    suspend(0);
		  endif
		  if (valid(o) && "f" in properties(o))
		    notify(player, tostr("*** ", o.name, " (", o,
				         ") has an `f' property!"));
		  endif
		endfor
   After eliminating all such properties from the database and restarting with
   this version of the server, you should, as a wizard, run the following MOO
   code to initialize the `f' bits of all of the objects:
		for i in [0..tonum(max_object())]
		  o = toobj(i);
		  if (ticks_left() < 1000 || seconds_left() < 2)
		    notify(player, tostr("Fixing ", o, ".f ..."));
		    suspend(0);
		  endif
		  if (valid(o))
		    o.f = o.r;
		  endif
		endfor
-- Reorganized the files so that all database modifying procedures were in one
   of four modules. (Version 1.6.8)
-- Reorganized existing network protocol and multiplexing wait implementations
   into a pluggable modular form. (Version 1.6.9)
-- Fixed bug in the interpreter that could pass a garbage program counter to
   the line-number-finding code, used in printing error tracebacks.  The l-n-f
   code responded semi-robustly by printing a message in the server log and
   returning a line number of zero. (Version 1.6.10)
-- Fixed bug whereby passing negative numbers to random() failed to evoke an
   E_INVARG error.
-- Fixed a bug in MOO-code compilation that led to real nastiness if there were
   more than 255 literals in a single verb.
-- Incorporated several new networking implementations, allowing for use by a
   single-user (using the standard input and output streams of the server
   itself), and by multiple users on either System V or BSD-style UNIX systems,
   either with or without TCP/IP networking.  (Version 1.6.11)
-- Fixed a bug in built-in function management that caused max() and min() to
   always raise E_TYPE on some systems.
-- Added a new automatic configuration system to the server distribution, so
   that people do not, in general, need to know much of anything about their
   local system in order to compile the server.  (Version 1.6.12)
-- Fixed a misfeature of substitute whereby it was not possible to include a
   percent-sign in the string that was to survive into the output.  Now, `%%'
   is replaced by `%' in the output.  (Version 1.7.0)

From max.fiu.edu!fontes0i Fri Oct 23 23:39:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "23" "October" "1992" "23:13:56" "-0700" "Ibis Fontes" "fontes0i@max.fiu.edu " nil "33" "HELP!!  HELP!!" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29592>; Fri, 23 Oct 1992 23:39:36 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12423>; Fri, 23 Oct 1992 23:37:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12426>; Fri, 23 Oct 1992 23:34:44 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Fri, 23 Oct 1992 23:23:55 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12418>; Fri, 23 Oct 1992 23:23:26 PDT
Received: from maxgw.fiu.edu ([131.94.64.6]) by alpha.xerox.com with SMTP id <12417>; Fri, 23 Oct 1992 23:22:57 PDT
Received: by maxgw.fiu.edu 
	(5.59/LAI-3.2) id AA15904; Sat, 24 Oct 92 02:13:56 EDT
X-NS-Transport-ID: 08002008D0FD002F0496
Message-ID: <9210240613.AA15904@maxgw.fiu.edu>
Date:	Fri, 23 Oct 1992 23:13:56 -0700
From:	fontes0i@max.fiu.edu (Ibis Fontes)
To:	59052803s@servax.fiu.edu, 59354970z@servax.fiu.edu,
	Moo-Cows.PARC@xerox.com
Subject: HELP!!  HELP!!


          (__)     Howdy Fellow Mooers!
          (oo)   
   /-------\/      I have run into a bit of a problem and I am
  / |     ||       asking you all for help.  Some friends and I 
 *  ||----||       came up with a cool theme and we decided to 
    ^^    ^^       start our own MOO.  We were able to set up the
database and all until it was working perfectly.  We worked on it
for two weeks and had achomplished quite a lot.  All was going well,
and we were all very proud.

Now recently, we came across a huge problem that makes the future
existence of our MOO look dreary.  It seems we may no longer keep
it in the machine it originally was on.  We had to shut it down and
put our plans on hold.

I come before you all petitioning that if there is anyplace out
there where we can run this thing for more than a temporary bases,
please contact me and let me know the location and any restrictions
that comes along with it.  

There already exist dependable people on this system who can take care
of day to day activities such as shut-down, etc..  All we need is some
place to put it where it may remain active and reachable both via
telnet and FTP.

If anyone has any suggestions as to whom I should contact, please feel
free to submit it.  Any help will be greatly appreciated.

Thanks in Advance,

A_Smile @ LambdaMOO


From cheshire.oxy.edu!t_pascal Sat Oct 24 13:48:33 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "24" "October" "1992" "13:37:11" "-0700" "C. Regis Wilson" "t_pascal@cheshire.oxy.edu " nil "16" "ftp oddities on beta" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 24 Oct 1992 13:48:31 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12637>; Sat, 24 Oct 1992 13:47:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12636>; Sat, 24 Oct 1992 13:44:27 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Sat, 24 Oct 1992 13:38:07 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12634>; Sat, 24 Oct 1992 13:37:55 PDT
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <12634>; Sat, 24 Oct 1992 13:37:14 PDT
Received: from cheshire.oxy.edu by gate.oxy.edu (4.0/SMI-4.0)
	id AA03292; Sat, 24 Oct 92 13:37:24 PDT
Received: by cheshire.oxy.edu (4.1/SMI-4.1)
	id AA17574; Sat, 24 Oct 92 13:37:11 PDT
X-NS-Transport-ID: 08002008D0FD002F0980
Message-ID: <9210242037.AA17574@cheshire.oxy.edu>
Date:	Sat, 24 Oct 1992 13:37:11 -0700
From:	t_pascal@cheshire.oxy.edu (C. Regis Wilson)
To:	moo-cows.PARC@xerox.com
Subject: ftp oddities on beta


On the ftp site (beta) the 1.7.0 distribution of LambdaMOO is publicly
writable...  Not that I don't trust everyone (which I don't :), but it
should not be publicly writable.

Also, what is foo.tar.Z in /pub/MOO/contrib?  It appears to be some lambda
distribution, but it's anybody's guess.

Ho, ho, I'll just shut up now.

---------
T. Pascal, King of Pascal    |  "The man on the moon told us he subsisted by
1600 Campus Road, Box 829    |   digging up cheese from his back yard.
Los Angeles, CA 90041        |   Unfortunately, he never told us what kind
                             |   it was."  -Word Perfect to PCWrite manual
   t_pascal@{{{cub,jaguar,cheetah}.math},bobcat,cheshire,tiger}.oxy.edu 

From parc.xerox.com!pavel Sun Oct 25 00:06:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "24" "October" "1992" "23:56:17" "-0700" "Pavel Curtis" "pavel@parc.xerox.com" nil "10" "Version 1.7.0 of the LambdaMOO Programmer's Manual" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 00:05:53 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12756>; Sun, 25 Oct 1992 00:04:34 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12781>; Sun, 25 Oct 1992 00:02:44 PDT
Received: by lambda.parc.xerox.com id <58375>; Sat, 24 Oct 1992 23:56:31 -0700
X-NS-Transport-ID: 08002008D0FD002F0CCB
Message-ID: <92Oct24.235631pdt.58375@lambda.parc.xerox.com>
Date:	Sat, 24 Oct 1992 23:56:17 -0700
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Version 1.7.0 of the LambdaMOO Programmer's Manual

I have finished tidying up the LambdaMOO Programmer's Manual to make it
consistent with release 1.7.0 of the server.  The new text is available for
anonymous FTP on parcftp.xerox.com in

	pub/MOO/ProgrammersManual.{texinfo,txt,ps,ps.Z,dvi,dvi.Z}

The new release of LambdaCore.db will be made available sometime tomorrow
afternoon, Sunday 25 October.

	Pavel/Haakon

From nova.decio.nd.edu!jonathan Sun Oct 25 05:33:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "05:30:57" "-0800" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " nil "22" "Re: Version 1.7.0 of the LambdaMOO Programmer's Manual" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 05:33:29 -0800
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <12799>; Sun, 25 Oct 1992 05:32:59 PST
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA23066; Sun, 25 Oct 92 08:30:58 EST
Message-Id: <9210251330.AA23066@nova.decio.nd.edu>
In-Reply-To: <92Oct24.235631pdt.58375@lambda.parc.xerox.com>; from "Pavel Curtis" at Oct 24, 92 11:56 pm
X-Mailer: ELM [version 2.3 PL11]
Date:	Sun, 25 Oct 1992 05:30:57 -0800
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	pavel@parc.xerox.com (Pavel Curtis)
Cc:	MOO-Cows@parc.xerox.com
Subject: Re: Version 1.7.0 of the LambdaMOO Programmer's Manual

> 
> I have finished tidying up the LambdaMOO Programmer's Manual to make it
> consistent with release 1.7.0 of the server.  The new text is available for
> anonymous FTP on parcftp.xerox.com in
> 
> 	pub/MOO/ProgrammersManual.{texinfo,txt,ps,ps.Z,dvi,dvi.Z}
> 
> The new release of LambdaCore.db will be made available sometime tomorrow
> afternoon, Sunday 25 October.
> 
> 	Pavel/Haakon
> 
Could you or is there a list of changes from the last core to this one
to support the 1.7.0 changes such as clear props and fertile objects?
I assume @chmod needs updating but what other core verbs have been added
or changed to support 1.7.0?

-- 
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -

From computing-maths.cardiff.ac.uk!Andrew.Wilson Sun Oct 25 06:22:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "06:07:55" "-0800" "Andrew Wilson" "Andrew.Wilson@computing-maths.cardiff.ac.uk" nil "23" "" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 06:22:37 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12801>; Sun, 25 Oct 1992 06:21:07 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12803>; Sun, 25 Oct 1992 06:19:41 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Sun, 25 Oct 1992 06:08:59 -0800
Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <12801>; Sun, 25 Oct 1992 06:08:37 PST
Via: uk.ac.cardiff.computing-maths; Sun, 25 Oct 1992 14:07:57 +0000
Received: from cm.cf.ac.uk by sentinel.cm.cf.ac.uk with SMTP (PP) 
          id <03098-0@sentinel.cm.cf.ac.uk>; Sun, 25 Oct 1992 14:08:10 +0000
X-NS-Transport-ID: 08002008D0FD002F0DD9
Message-ID: <9210251407.AA13853@sapphire.cm.cf.ac.uk>
Date:	Sun, 25 Oct 1992 06:07:55 -0800
From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
To:	MOO-Cows@parc.xerox.com


Hi,

	in options.h of the 1.7 server release we see:

 * Define OUTBOUND_NETWORK to enable the built-in MOO function
 * open_network_connection(), which allows (only) wizard-owned MOO code to make
 * outbound network connections from the server.
 * *** THINK VERY HARD BEFORE ENABLING THIS FUNCTION ***
 * In some contexts, this could represent a serious breach of security.  By
 * default, the open_network_connection() function is disabled, always raising
 * E_PERM when called.

	For the benefit of those not in the know (including me, I'm ashamed
to say), and more specifically to allay the concerns of my system boss,
could someone please say which 'contexts' really could 'represent a serious
breach of security'.
	Your answer may be sent in a plain brown wrapper (email) to avoid
insult to the 'morally challenged'.

Thanks,

  Andrew Wilson (Networker - proud to be a part of the 'social experiment')

From parc.xerox.com!pavel Sun Oct 25 14:54:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "14:44:38" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "12" "Re: Version 1.7.0 of the LambdaMOO Programmer's Manual" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Sun, 25 Oct 1992 14:54:55 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12825>; Sun, 25 Oct 1992 14:53:22 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12823>; Sun, 25 Oct 1992 14:51:11 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Sun, 25 Oct 1992 14:45:42 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12823>; Sun, 25 Oct 1992 14:45:09 PST
Received: by lambda.parc.xerox.com id <58378>; Sun, 25 Oct 1992 14:44:51 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F1050
In-Reply-to: <9210251330.AA23066@nova.decio.nd.edu>
Message-ID: <92Oct25.144451pst.58378@lambda.parc.xerox.com>
References: <9210251330.AA23066@nova.decio.nd.edu>
	<92Oct24.235631pdt.58375@lambda.parc.xerox.com>
Date:	Sun, 25 Oct 1992 14:44:38 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	jonathan@nova.decio.nd.edu
cc:	MOO-Cows@parc.xerox.com
Subject: Re: Version 1.7.0 of the LambdaMOO Programmer's Manual

> Date:	Sun, 25 Oct 1992 05:30:57 -0800
> From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)

> Could you or is there a list of changes from the last core to this one
> to support the 1.7.0 changes such as clear props and fertile objects?
> I assume @chmod needs updating but what other core verbs have been added
> or changed to support 1.7.0?

I didn't make any of the core DB changes to support the new features; I think
that yduJ did most of them.  yduJ?

	Pavel

From parc.xerox.com!pavel Sun Oct 25 14:59:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "14:49:08" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "19" "Why not #define OUTBOUND_NETWORK?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Sun, 25 Oct 1992 14:59:26 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12826>; Sun, 25 Oct 1992 14:58:03 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12825>; Sun, 25 Oct 1992 14:56:16 PST
Received: by lambda.parc.xerox.com id <58379>; Sun, 25 Oct 1992 14:51:17 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F105B
In-Reply-to: <9210251407.AA13853@sapphire.cm.cf.ac.uk>
Message-ID: <92Oct25.145117pst.58379@lambda.parc.xerox.com>
References: <9210251407.AA13853@sapphire.cm.cf.ac.uk>
Date:	Sun, 25 Oct 1992 14:49:08 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	Andrew.Wilson@computing-maths.cardiff.ac.uk
cc:	MOO-Cows@parc.xerox.com
Subject: Why not #define OUTBOUND_NETWORK?

> Date:	Sun, 25 Oct 1992 06:07:55 -0800
> From:	Andrew Wilson <Andrew.Wilson@computing-maths.cardiff.ac.uk>
> 
> 	For the benefit of those not in the know (including me, I'm ashamed
> to say), and more specifically to allay the concerns of my system boss,
> could someone please say which 'contexts' really could 'represent a serious
> breach of security'.

We do not #define OUTBOUND_NETWORK on LambdaMOO itself, for example, because
lambda.parc.xerox.com is directly connected to an internal network within
Xerox.  Packets only reach lambda from the outside because of a special
dispensation in our boundary routers; most outside packets are simply dropped.
Were we to allow arbitrary outbound connections from lambda, that would allow
people outside of Xerox to connect to other machines inside of Xerox,
compromising their security assumptions.

This is the kind of context I had in mind when I wrote that comment.

	Pavel

From wvnvaxa.wvnet.edu!UN032233 Sun Oct 25 16:28:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "15:19:41" "-0800" "Gilmore" "UN032233@wvnvaxa.wvnet.edu" nil "11" "Proposed function: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 16:28:01 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12828>; Sun, 25 Oct 1992 16:26:50 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12829>; Sun, 25 Oct 1992 16:24:52 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58380>; Sun, 25 Oct 1992 16:20:08 -0800
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12829>; Sun, 25 Oct 1992 16:19:48 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQDKKO1CWG9VUKX7@WVNVMS.WVNET.EDU>; Sun, 25 Oct 1992 19:19:41 EDT
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002F10CC
Message-ID: <01GQDKKO1CWI9VUKX7@WVNVMS.WVNET.EDU>
Date:	Sun, 25 Oct 1992 15:19:41 -0800
From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
To:	moo-cows@parc.xerox.com
Subject: Proposed function: notify_ascii()

This seems like an extremly easily-programmed function: a variant of notify
which would allow one to send an ascii character, such as an ESC for the
implementation of vt100 or ansi command sequences.  Then one would be able to
create an object $screen_utils with verbs like :up, :down, :color, :clear, and
so on, and perhaps a prop $player.term_type which this would access.  At
any rate, it seems like a trivial capability to add, although I certainly have
no experience with hacking the server.

Could someone tell me why this would be a bad idea?

				- Gilmore

From stony-brook.scrc.symbolics.com!yduJ Sun Oct 25 17:01:06 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "17:01:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "5" "Why not #define OUTBOUND_NETWORK?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 17:01:02 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12830>; Sun, 25 Oct 1992 17:00:38 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1163769; 25 Oct 1992 19:59:26-0500
In-Reply-To: <92Oct25.145117pst.58379@lambda.parc.xerox.com>
Message-ID: <19921026010120.4.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Sun, 25 Oct 1992 17:01:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	Pavel@parc.xerox.com, Andrew.Wilson@computing-maths.cardiff.ac.uk
cc:	MOO-Cows@parc.xerox.com
Subject: Why not #define OUTBOUND_NETWORK?

Using slightly plainer english than Pavel, if your computer already
allows incoming network connections from the outside world for telnet,
FTP, etc., then you won't incur any additional risk by allowing
open_network_connection.  NFS is done with UDP, not TCP, so it's not a
risk.

From stony-brook.scrc.symbolics.com!yduJ Sun Oct 25 17:05:06 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "16:58:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "31" "Proposed function: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 17:05:03 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12832>; Sun, 25 Oct 1992 17:04:12 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12831>; Sun, 25 Oct 1992 17:02:30 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58381>; Sun, 25 Oct 1992 16:57:58 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12828>; Sun, 25 Oct 1992 16:57:41 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1163766; 25 Oct 1992 19:56:27-0500
X-NS-Transport-ID: 08002008D0FD002F10F4
In-Reply-to: <01GQDKKO1CWI9VUKX7@WVNVMS.WVNET.EDU>
Message-ID: <19921026005826.3.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Sun, 25 Oct 1992 16:58:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	UN032233@wvnvaxa.wvnet.edu, moo-cows@parc.xerox.com
Subject: Proposed function: notify_ascii()

    Date: Sun, 25 Oct 1992 18:19 EST
    From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>

    This seems like an extremly easily-programmed function: a variant of notify
    which would allow one to send an ascii character, such as an ESC for the
    implementation of vt100 or ansi command sequences.  Then one would be able to
    create an object $screen_utils with verbs like :up, :down, :color, :clear, and
    so on, and perhaps a prop $player.term_type which this would access.  At
    any rate, it seems like a trivial capability to add, although I certainly have
    no experience with hacking the server.

    Could someone tell me why this would be a bad idea?

				    - Gilmore

The reasons that it's generally a bad idea to allow arbitrary escape
sequences to be sent to your terminal are generally those of security
assumptions by the specific terminal.  In old HP terminals (HP26xx's)
you could program a softkey via escape sequences and make the terminal
pretend you hit a softkey, in effect, forcing the user to do arbitrary
typein of your choice from their userid.  Bad idea...  I don't know if
there are still other terminals with this sort of capability, but I
imagine there are.  In the absence of malicious users, such capabilities
are a boon (and presumably HP didn't think about interactive games
played with people from around the world when they designed their
terminals...)

If you are running on a terminal which you *know* won't be compromised
by such tricks, then there really isn't any risk.  (Well, someone might
make it print in chartreuse on mauve and you'd barf, but other than
that...)

From wvnvaxa.wvnet.edu!UN032233 Sun Oct 25 17:14:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "16:03:59" "-0800" "Gilmore" "UN032233@wvnvaxa.wvnet.edu" nil "22" "Re: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 17:14:04 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12828>; Sun, 25 Oct 1992 17:12:33 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12832>; Sun, 25 Oct 1992 17:11:23 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58383>; Sun, 25 Oct 1992 17:07:00 -0800
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12830>; Sun, 25 Oct 1992 17:04:04 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQDM2WWFB49VULC7@WVNVMS.WVNET.EDU>; Sun, 25 Oct 1992 20:03:59 EDT
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002F1101
Message-ID: <01GQDM2WWOYA9VULC7@WVNVMS.WVNET.EDU>
Date:	Sun, 25 Oct 1992 16:03:59 -0800
From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: notify_ascii()

Amazing ... for every feature, there's a security risk.  Alas.  Perhaps a
compile-time option similar to that for open_network_connection(), call it
OUTBOUND_ASCII or some such?  But that doesn't really put responsibility
where it should be, since the risk for notify_ascii() is to the _player_,
not the system.

Still, in connecting though telnet to another system normally, you're giving
implicit permission for that system to send you whatever character-sequences
it needs to send in order to get its job done; things such as editors send
such sequences, and I presume this means that on a terminal such as that
which yduJ described, one could write a file and send it to someone which
would actually FORCE him to type commands?  This seems ludicrous.  And the
only way I can see for it to be abused is for some wizard on a MOO to write
a malicious verb, and even then it would ONLY work on players with that term
type.  This doesn't seem to be enough risk to outweigh the GREAT benefits
of being able to send escape-sequences.  And they are great; imagine a full
screen editor for a MOO, or (more light-heartedly) MOO-tetris.  Or a visual
movement system for something like a cybernetic matrix.

Pavel, how about it? :)

				- Gilmore

From cs.stanford.edu!crew Sun Oct 25 17:30:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "17:23:30" "-0800" "Roger Crew" "crew@cs.stanford.edu" nil "24" "Re: Why not #define OUTBOUND_NETWORK?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Sun, 25 Oct 1992 17:30:35 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12841>; Sun, 25 Oct 1992 17:29:16 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12839>; Sun, 25 Oct 1992 17:27:58 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58384>; Sun, 25 Oct 1992 17:23:43 -0800
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <12836>; Sun, 25 Oct 1992 17:23:22 PST
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA08896; Sun, 25 Oct 92 17:23:30 PST
X-NS-Transport-ID: 08002008D0FD002F111F
In-Reply-to: "Your message of \"Sun, 25 Oct 92 17:01:00 PST.\"
             <19921026010120.4.YDUJ@JACKS-PLACE.sharon.symbolics.com>ui"
Message-ID: <9210260123.AA08896@Xenon.Stanford.EDU>
Date:	Sun, 25 Oct 1992 17:23:30 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: Why not #define OUTBOUND_NETWORK?

>   Using slightly plainer english than Pavel, if your computer already
>   allows incoming network connections from the outside world for telnet,
>   FTP, etc., then you won't incur any additional risk by allowing
>   open_network_connection.  NFS is done with UDP, not TCP, so it's not a
>   risk.

Actually, there are still some (minor) risks.  If you enable outbound
connections and your MOO's internal security fails somehow (e.g.,
someone cracks a wizard bit -- keep in mind that this happens
occasionally), then what you have, effectively, is a way for some
random person on the network to use your machine to initiate any kind
of TCP connection he wants that your machine is able to do.  And there are 
services out there that might be relying on your machine to have done
some sort of authentication before initating such a connection.

Consider, e.g., someone using open_network_connection() to port 25 to
forge email.  It would be traceable only as far back as your machine
(unless there are records internal to the MOO, though if someone's
cracked a wizard bit, you might not be able to trust these)

--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

From stony-brook.scrc.symbolics.com!yduJ Sun Oct 25 17:30:38 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "17:30:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "26" "Re: Version 1.7.0 of the LambdaMOO Programmer's Manual" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 17:30:35 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12836>; Sun, 25 Oct 1992 17:29:23 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1163778; 25 Oct 1992 20:28:15-0500
In-Reply-To: <92Oct25.144451pst.58378@lambda.parc.xerox.com>
Message-ID: <19921026013008.5.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Sun, 25 Oct 1992 17:30:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	Pavel@parc.xerox.com, jonathan@nova.decio.nd.edu
cc:	MOO-Cows@parc.xerox.com
Subject: Re: Version 1.7.0 of the LambdaMOO Programmer's Manual

    Date: Sun, 25 Oct 1992 17:44 EST
    From:	Pavel Curtis <Pavel@parc.xerox.com>

    > Date:	Sun, 25 Oct 1992 05:30:57 -0800
    > From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)

    > Could you or is there a list of changes from the last core to this one
    > to support the 1.7.0 changes such as clear props and fertile objects?
    > I assume @chmod needs updating but what other core verbs have been added
    > or changed to support 1.7.0?

    I didn't make any of the core DB changes to support the new features; I think
    that yduJ did most of them.  yduJ?

:looks around behind her.  Hmm, no backup forces in sight.

@chmod, $recycler:_recreate, $building_utils:recreate, @prospectus,
@display, $code_utils:show_object.  I don't remember if old cores have
.owned_objects; if so, @prospectusDB as well.
$object_utils:property_conflicts (possibly new since last core)
$generic_help:initialize (set it to 0).

I can't find any others with @grepcore \"f\" or @grepcore .f (I didn't
actually remember what all needed to be done.)

Happy converting.

From stony-brook.scrc.symbolics.com!yduJ Sun Oct 25 17:30:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "17:31:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "20" "Re: Version 1.7.0 of the LambdaMOO Programmer's Manual" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 25 Oct 1992 17:30:50 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12842>; Sun, 25 Oct 1992 17:30:31 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1163779; 25 Oct 1992 20:29:23-0500
In-Reply-To: <92Oct25.144451pst.58378@lambda.parc.xerox.com>
Message-ID: <19921026013117.6.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Sun, 25 Oct 1992 17:31:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	Pavel@parc.xerox.com, jonathan@nova.decio.nd.edu
cc:	MOO-Cows@parc.xerox.com
Subject: Re: Version 1.7.0 of the LambdaMOO Programmer's Manual

    Date: Sun, 25 Oct 1992 17:44 EST
    From:	Pavel Curtis <Pavel@parc.xerox.com>

    > Date:	Sun, 25 Oct 1992 05:30:57 -0800
    > From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)

    > Could you or is there a list of changes from the last core to this one
    > to support the 1.7.0 changes such as clear props and fertile objects?
    > I assume @chmod needs updating but what other core verbs have been added
    > or changed to support 1.7.0?

    I didn't make any of the core DB changes to support the new features; I think
    that yduJ did most of them.  yduJ?

	    Pavel

Note that Pavel *did* run a verb to clear all the properties in the DB
whose values were the same as their ancestors.  Check out #2:clear_all
on Lambda (tho it's obviously been hacked once; apparently it broke
halfway though?)

From parc.xerox.com!pavel Sun Oct 25 17:46:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "17:31:54" "-0800" "Pavel Curtis" "pavel@parc.xerox.com" nil "8" "New LambdaCore.db Released" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Sun, 25 Oct 1992 17:46:37 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12841>; Sun, 25 Oct 1992 17:45:00 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12844>; Sun, 25 Oct 1992 17:42:57 PST
Received: by lambda.parc.xerox.com id <58387>; Sun, 25 Oct 1992 17:38:41 -0800
X-NS-Transport-ID: 08002008D0FD002F113F
Message-ID: <92Oct25.173841pst.58387@lambda.parc.xerox.com>
Date:	Sun, 25 Oct 1992 17:31:54 -0800
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: New LambdaCore.db Released

A new release of the LambdaCore database, extracted from LambdaMOO today, is
now available for anonymous FTP from parcftp.xerox.com, in the file

		pub/MOO/LambdaCore-25Oct92.db

Enjoy!

	Pavel/Haakon

From suna0.cs.uiuc.edu!scott Sun Oct 25 17:49:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "25" "October" "1992" "17:40:53" "-0800" "Jay Scott" "scott@suna0.cs.uiuc.edu" nil "15" "Re: Why not #define OUTBOUND_NETWORK?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Sun, 25 Oct 1992 17:49:07 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12846>; Sun, 25 Oct 1992 17:48:20 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12842>; Sun, 25 Oct 1992 17:47:03 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58389>; Sun, 25 Oct 1992 17:43:02 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12842>; Sun, 25 Oct 1992 17:41:59 PST
Received: from sparc5.cs.uiuc.edu ([128.174.244.115]) by alpha.xerox.com with SMTP id <12841>; Sun, 25 Oct 1992 17:41:35 PST
Received: by sparc5.cs.uiuc.edu id AA03618
  (5.65c/IDA-1.4.4 for moo-cows@xerox.com); Sun, 25 Oct 1992 19:40:53 -0600
X-NS-Transport-ID: 08002008D0FD002F113A
Message-ID: <199210260140.AA03618@sparc5.cs.uiuc.edu>
Date:	Sun, 25 Oct 1992 17:40:53 -0800
From:	Jay Scott <scott@suna0.cs.uiuc.edu>
To:	moo-cows.PARC@xerox.com
Subject: Re: Why not #define OUTBOUND_NETWORK?

There is another risk to open_network_connection(), though
I don't know how serious it might be. MOO players usually
enjoy some amount of anonymity. From a cracker's point of view,
that makes it sort of like a dial-up telnet server: a
handy obstacle to throw in the way of back-trace attempts.

There are plenty of dial-up telnet servers in the world, so
I guess it's not a world-shaking danger. You might consider
restricting the allowed connections in some way (Thou Shalt
Connect Only to Wizard-Approved Sites). If I were running a
public MOO, I'd log all the open_network_connection()
calls, just in case it turned out helpful someday.

	Frand
	scott@cs.uiuc.edu

From unipress.com!joe Mon Oct 26 06:20:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "06:11:01" "-0800" "joe@unipress.com" "joe@unipress.com" nil "32" "Re: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 26 Oct 1992 06:20:51 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11620>; Mon, 26 Oct 1992 06:19:05 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11602>; Mon, 26 Oct 1992 06:15:49 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 06:11:45 -0800
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <11602>; Mon, 26 Oct 1992 06:11:25 PST
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA20083; Mon, 26 Oct 92 09:11:13 EST
Received: from dot.UniPress.COM by repo.unipress.com (4.1/SMI-4.1/UniPress121791.1)
	id AA07444; Mon, 26 Oct 92 09:11:07 EST via
X-NS-Transport-ID: 08002008D0FD002F1635
In-Reply-to: "Your message of \"Sun, 25 Oct 92 16:03:59 PST.\"
             <01GQDM2WWOYA9VULC7@WVNVMS.WVNET.EDU> have"
Message-ID: <9210261411.AA07444@repo.unipress.com>
Date:	Mon, 26 Oct 1992 06:11:01 -0800
From:	joe@unipress.com
To:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
cc:	moo-cows@parc.xerox.com, joe@unipress.com
Subject: Re: notify_ascii()



> the risk for notify_ascii() is to the _player_,
> not the system.

Yup.  That makes it even more difficult to deal with.

> Still, in connecting though telnet to another system normally, you're giving
> implicit permission for that system to send you whatever character-sequences
> it needs to send in order to get its job done

When I normally telnet to another system, I run programs which I trust.  In a
MOO setting, this is not always the case.

What is *really* needed for more fancy output from MUDs in general are more
specialized clients.  I'm not going to reheat all the reasons for this, but
one of them is that merely sending terminal escape sequences in MUD output is
not general or powerful enough for everything that one might want to do.  

I am given to understand that some work in this area is already going on. 
Astro-VR (?) for example, allows folks to display images stored "on the MOO"
(actually a pointer to an ftp site for the right image files, I think) on
their bitmapped terminals through the use of a smart emacs client.

According to tantalizing hints in Pavel's letters to MOO-cows, there is some
code for 'window-based interfaces to MOO objects' on the way in the form of a
project named Jupiter.  Enquiring minds want to know.

The general feeling on fancy MUD output seems to me to be aimed a bit higher
than just doing cute things on your terminal, anyway.

-K*

From garfield.cs.mun.ca!byron Mon Oct 26 12:23:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "12:14:24" "-0800" "Byron Montgomerie" "byron@garfield.cs.mun.ca" nil "15" "Escape-characters" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Mon, 26 Oct 1992 12:23:36 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11690>; Mon, 26 Oct 1992 12:23:02 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11674>; Mon, 26 Oct 1992 12:19:58 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 12:16:38 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11618>; Mon, 26 Oct 1992 12:16:16 PST
Received: from garfield.cs.mun.ca ([134.153.1.1]) by alpha.xerox.com with SMTP id <11634>; Mon, 26 Oct 1992 12:15:34 PST
Received: by garfield.cs.mun.ca id <110921>; Mon, 26 Oct 1992 16:44:29 -0330
X-NS-Transport-ID: 08002008D0FD002F1D7B
Message-ID: <92Oct26.164429nst.110921@garfield.cs.mun.ca>
Date:	Mon, 26 Oct 1992 12:14:24 -0800
From:	Byron Montgomerie <byron@garfield.cs.mun.ca>
To:	moo-cows.PARC@xerox.com
Subject: Escape-characters

Escape characters are easy enough to send, the problem with full screen editors is the need to get single character input. All this was discussed in 
Server-Hackers on Lambda.  Emacs also spits out any escape characters it
receives so that is another limitation.  I had problems also with having to
redo the escape code hack I made to work with new versions of the server.
Unless you are willing to keep a core that doesn't implement the escape codes
you have to redo any hacks like this.


 Byron... (Tarod@Lambda@FinalFrontier@InterMOO)
 ___________________________________________________________________________
|     ///    "Byron Montgomerie"  Internet: byron@odie.cs.mun.ca       ///  |
| \\\///      "Does anybody here remember Vera Lynn?               \\\///   |
|  \///        How she said that we would meet again,               \///    |
|  Amiga       some sunny day..." -- Pink Floyd --                 Amiga    |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From cs.stanford.edu!crew Mon Oct 26 15:32:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "15:24:37" "-0800" "Roger Crew" "crew@cs.stanford.edu" nil "51" "Re: Proposed function: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 26 Oct 1992 15:32:34 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11689>; Mon, 26 Oct 1992 15:31:44 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11684>; Mon, 26 Oct 1992 15:28:24 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 15:25:05 -0800
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11672>; Mon, 26 Oct 1992 15:24:36 PST
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA20531; Mon, 26 Oct 92 15:24:39 PST
X-NS-Transport-ID: 08002008D0FD002F220A
In-Reply-to: "Your message of \"Sun, 25 Oct 92 15:19:41 PST.\"
             <01GQDKKO1CWI9VUKX7@WVNVMS.WVNET.EDU>rm of"
Message-ID: <9210262324.AA20531@Xenon.Stanford.EDU>
Date:	Mon, 26 Oct 1992 15:24:37 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: Proposed function: notify_ascii()

Actually the real objection to this is more on philosophical grounds rather 
than security grounds.  For this to be useful, the MOO server would
then have to be informed about the proper escape sequences to use to
perform the desired operations on *every* kind of terminal in
existence.  

Granted, the argument could be made that LambdaCore is so bloated now
that no one would notice the addition of /etc/termcap.  However, the
problem of keeping the proposed LambdaCore terminal database (call it
"MOO-termcap") up to date is actually slightly *worse* than the
problem of keeping an /etc/termcap up to date, since we'd be talking
about maintaining centrally something that is best maintained locally

    Loser pages, "Hi Haakon, I need a new MOO-termcap entry for hazeltine-1000-
      with-a-fried-somethingorother-card so that all of these neat LambdaMOO 
      display thingies will work with my braindamaged terminal."  
    Haakon responds with much enthusiasm.

Life is much easier if only the client program has to know about
manipulating the terminal.  This is not to say that wanting to do
simple terminal operations from MOO-code is a bad thing; merely that
there are much better ways to do it than teaching the MOO server about
all terminals in existence and having the MOO server send the right
escape sequences directly.  In particular, we shouldn't be contorting MOO
to deal with the limitations of the telnet client.

The right way to do this is to have one or more published protocols
for doing screen manipulations on clients and then a property on each
player specifying which protocol is in use.  E.g., one could have a
protocol like

   ~~   =>  ~
   ~P   =>  highlight on
   ~Q   =>  highlight off
   ~L   =>  clear the screen
   ~^J  =>  end of line without a return (for queries...)
   ...

and then we spend our effort on clients that know how render particular 
~-sequences.  There would still be a "MOO-termcap" of sorts but it would 
only refer to protocols and not be tied to any particular hardware.

Note that if graphical muds are what you really want, then you
probably want to be using X or something of that ilk for your protocol, 
though this would have to wait for another order-of-magnitude increase 
in cross-country network bandwidth.  This would be a completely different
animal though...
--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

From aero.org!obrien Mon Oct 26 15:48:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "15:43:08" "-0800" "Mike O'Brien" "obrien@aero.org" nil "14" "Re: Proposed function: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 26 Oct 1992 15:48:51 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11666>; Mon, 26 Oct 1992 15:47:56 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11688>; Mon, 26 Oct 1992 15:45:44 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 15:43:45 -0800
Received: from aerospace.aero.org ([130.221.192.10]) by alpha.xerox.com with SMTP id <11608>; Mon, 26 Oct 1992 15:43:26 PST
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
	id AA12476 for moo-cows@parc.xerox.com; Mon, 26 Oct 1992 15:43:10 -0800
Posted-Date: Mon, 26 Oct 92 15:43:08 PST
Received: from anpiel.aero.org by antares.aero.org (4.1/AMS-1.0)
	id AA22060 for crew@cs.stanford.edu; Mon, 26 Oct 92 15:43:09 PST
X-NS-Transport-ID: 08002008D0FD002F225A
In-Reply-to: "Your message of \"Mon, 26 Oct 92 15:24:37 PST.\"
             <9210262324.AA20531@Xenon.Stanford.EDU>"
Message-ID: <199210262343.AA12476@aerospace.aero.org>
Date:	Mon, 26 Oct 1992 15:43:08 -0800
From:	Mike O'Brien <obrien@aero.org>
To:	Roger Crew <crew@cs.stanford.edu>
cc:	moo-cows@parc.xerox.com
Subject: Re: Proposed function: notify_ascii()

>Life is much easier if only the client program has to know about
>manipulating the terminal. ...
>The right way to do this is to have one or more published protocols
>for doing screen manipulations on clients and then a property on each
>player specifying which protocol is in use.

This was first invented years ago, in the Arpanet SUPDUP protocol.  It
specified just about all the cursor-motion stuff on alphanumeric
terminals, and used a server-client pair to have the translation to
actual terminal codes done at the client end.

For whatever reason, this never caught on, and SUPDUP has recently
been officially decomissioned by those whose job it is to throw
away old Internet protocols.

From nova.decio.nd.edu!jonathan Mon Oct 26 16:13:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "16:04:20" "-0800" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " nil "31" "Linux w/1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 26 Oct 1992 16:13:37 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11697>; Mon, 26 Oct 1992 16:12:11 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11608>; Mon, 26 Oct 1992 16:09:27 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 16:07:11 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11689>; Mon, 26 Oct 1992 16:06:49 PST
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <11608>; Mon, 26 Oct 1992 16:06:20 PST
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA28647; Mon, 26 Oct 92 19:04:22 EST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002F22C1
Message-ID: <9210270004.AA28647@nova.decio.nd.edu>
Date:	Mon, 26 Oct 1992 16:04:20 -0800
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	MOO-Cows@xerox.com (Moo-Cows)
Subject: Linux w/1.7.0

Hmm. Something has changed between 1.6.1 and 1.7.0 that causes my compiler
to go nuts. GCC 2.2.2d on Linux .98.1....


gcc -O -Wall -Wwrite-strings  -g -DMOO  -c ast.c -o ast.o
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c db.c -o db.o
In file included from /usr/include/sys/time.h:5, from /usr/include/unistd.h:182, from my-unistd.h:22, from db.c:21:
/usr/include/linux/time.h:15: warning: `FD_SET' redefined
my-types.h:28: warning: this is the location of the previous definition
/usr/include/linux/time.h:17: warning: `FD_ISSET' redefined
my-types.h:29: warning: this is the location of the previous definition
/usr/include/linux/time.h:18: warning: `FD_ZERO' redefined
my-types.h:27: warning: this is the location of the previous definition
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c db_property.c -o db_property.o
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c db_verb.c -o db_verb.o
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c eval_env.c -o eval_env.o
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c eval_vm.c -o eval_vm.o
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c exceptions.c -o exceptions.o
gcc -O -Wall -Wwrite-strings  -g -DMOO  -c execute.c -o execute.o
execute.c: In function `run':
execute.c:1197: fixed or forbidden register was spilled.
This may be due to a compiler bug or to impossible asm statements.
make: *** [execute.o] Error 1

Any ideas? This is the latest GCC I think for Linux.

-- 
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -

From nexus.yorku.ca!s442223 Mon Oct 26 16:28:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "16:18:54" "-0800" "s442223@nexus.yorku.ca" "s442223@nexus.yorku.ca" nil "14" "Re: Linux w/1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 26 Oct 1992 16:28:08 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11675>; Mon, 26 Oct 1992 16:27:01 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11682>; Mon, 26 Oct 1992 16:25:09 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 16:20:17 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11668>; Mon, 26 Oct 1992 16:19:56 PST
Received: from nexus.yorku.ca ([130.63.9.66]) by alpha.xerox.com with SMTP id <11668>; Mon, 26 Oct 1992 16:19:31 PST
Received: by nexus.yorku.ca id <9221>; Mon, 26 Oct 1992 19:19:09 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
X-NS-Transport-ID: 08002008D0FD002F2308
In-Reply-to: "jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
       \"Linux w/1.7.0\" (Oct 26,  7:04pm)!4%D`%#"
Message-ID: <92Oct26.191909est.9221@nexus.yorku.ca>
Date:	Mon, 26 Oct 1992 16:18:54 -0800
From:	s442223@nexus.yorku.ca
To:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
cc:	MOO-Cows.PARC@xerox.com
Subject: Re: Linux w/1.7.0


For some reason Linux seems to barf on execute.c if you are compiling with
optimization turned on. 

Do something like: gcc -c execute.c
and then restart make

The rest went fine for me.


-- 
Chaos is s442223@nexus.yorku.ca - only virtual in appearance, naked eyes cannot
Chaos is also N'vrekh Ianu tr'Fnavh ... go figger. Call him mud adminstrator 
for GodNet/Final Frontier. Hey whatever. The look. Get it. da da da. Bored yet?

From theory.cs.mankato.msus.edu!nop Mon Oct 26 17:15:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "17:09:05" "-0800" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "9" "Linux w/1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 26 Oct 1992 17:15:40 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11705>; Mon, 26 Oct 1992 17:14:27 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11690>; Mon, 26 Oct 1992 17:12:59 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 17:10:49 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11675>; Mon, 26 Oct 1992 17:10:05 PST
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11683>; Mon, 26 Oct 1992 17:09:28 PST
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA16118; Mon, 26 Oct 92 19:09:05 -0600
X-NS-Transport-ID: 08002008D0FD002F2401
In-Reply-to: "Jonathan Bradshaw's message of Mon, 26 Oct 1992 16:04:20 PST <9210270004.AA28647@nova.decio.nd.edu>"
Message-ID: <9210270109.AA16118@theory.cs.mankato.msus.edu>
Date:	Mon, 26 Oct 1992 17:09:05 -0800
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	jonathan@nova.decio.nd.edu
cc:	MOO-Cows.PARC@xerox.com
Subject: Linux w/1.7.0

> execute.c: In function `run':
> execute.c:1197: fixed or forbidden register was spilled.
> This may be due to a compiler bug or to impossible asm statements.

Looks like a compiler bug to me.  I'm going to wait for gcc 2.3, then
report it.

Jay Carlson
nop@theory.cs.mankato.msus.edu

From wvnvaxa.wvnet.edu!UN032233 Mon Oct 26 20:10:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "26" "October" "1992" "19:04:54" "-0800" "Gilmore" "UN032233@wvnvaxa.wvnet.edu" nil "18" "Re: notify_ascii()" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 26 Oct 1992 20:10:34 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11708>; Mon, 26 Oct 1992 20:10:06 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11700>; Mon, 26 Oct 1992 20:07:28 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 26 Oct 1992 20:05:27 -0800
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <11698>; Mon, 26 Oct 1992 20:05:03 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQF6OVSZFK9VUTGU@WVNVMS.WVNET.EDU>; Mon, 26 Oct 1992 23:04:54 EDT
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002F26B9
Message-ID: <01GQF6OVT92Q9VUTGU@WVNVMS.WVNET.EDU>
Date:	Mon, 26 Oct 1992 19:04:54 -0800
From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: notify_ascii()

Well, my only real purpose in suggesting such a thing was for people having
the OPTION to use this function in their MOO databases.  And I don't think a
MOO which used this option would have to support EVERY terminal; even just
supporting such terms as VT52/100/102 and ANSI would cover the very large
majority of users - a MOO isn't obligated to cover EVERY user, and players
without the terminals supported would have the option of simply not using
the features that required terminal escapes.  After all, my original motivation
for this was to experiment with making a simple in-DB fullscreen editor - not
to create an entire MOO based around whacky color fullscreen displays.

It still seems that this would be a very easy function to write.  And I think
other people would enjoy using this as well, all philosophical arguments aside.
After all, the open_network_connection() function is provided and many MOOs
don't use *that*...

Unfortunately, I don't have access to the C code of the MOO which I wiz on.

			- Gilmore

From parc.xerox.com!masinter Tue Oct 27 10:57:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "10:45:36" "-0800" "Larry Masinter" "masinter@parc.xerox.com" nil "14" "callers([task_id]) ?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 10:57:22 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11801>; Tue, 27 Oct 1992 10:55:06 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11799>; Tue, 27 Oct 1992 10:50:54 PST
Received: from poplar.parc.xerox.com ([13.2.16.165]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 27 Oct 1992 10:45:53 -0800
Received: by poplar.parc.xerox.com id <101795>; Tue, 27 Oct 1992 10:45:45 -0800
X-NS-Transport-ID: 08002008D0FD002F311C
Message-ID: <92Oct27.104545pst.101795@poplar.parc.xerox.com>
Date:	Tue, 27 Oct 1992 10:45:36 -0800
From:	Larry Masinter <masinter@parc.xerox.com>
To:	moo-cows@parc.xerox.com
Subject: callers([task_id]) ?

In order to track down run-away processes and the like, how about
having callers() accept an optional task_id argument? 

caller() == callers(task_id())

return E_PERM if !.wizard or task_id is not a task of caller_perms()
return E_INVARG if task is not a valid task.

We wouldn't need $command_utils.suspend_database in this case. I think
it would allow some better performance analysis tools.

This is information the server must have; I don't know how well the
server sources are structured to add this.


From parc.xerox.com!pavel Tue Oct 27 14:18:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "14:06:00" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "4" "Re: callers([task_id]) ?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 14:18:34 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11846>; Tue, 27 Oct 1992 14:16:39 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11839>; Tue, 27 Oct 1992 14:13:19 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 27 Oct 1992 14:06:57 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11844>; Tue, 27 Oct 1992 14:06:15 PST
Received: by lambda.parc.xerox.com id <58372>; Tue, 27 Oct 1992 14:06:10 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F354E
In-Reply-to: <92Oct27.104545pst.101795@poplar.parc.xerox.com>
Message-ID: <92Oct27.140610pst.58372@lambda.parc.xerox.com>
References: <92Oct27.104545pst.101795@poplar.parc.xerox.com>
Date:	Tue, 27 Oct 1992 14:06:00 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	masinter@parc.xerox.com
cc:	moo-cows@parc.xerox.com
Subject: Re: callers([task_id]) ?

I will try to remember to add this functionality in the next release.  I'd been
meaning to do so anyway...

	Pavel

From parc.xerox.com!pavel Tue Oct 27 14:23:17 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "14:15:25" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "31" "strcmp() portability note" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 14:23:08 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11843>; Tue, 27 Oct 1992 14:22:24 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11849>; Tue, 27 Oct 1992 14:20:44 PST
Received: by lambda.parc.xerox.com id <58373>; Tue, 27 Oct 1992 14:15:37 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F3575
Message-ID: <92Oct27.141537pst.58373@lambda.parc.xerox.com>
Date:	Tue, 27 Oct 1992 14:15:25 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: strcmp() portability note

It has been brought to my attention that the MOO's built-in function strcmp()
returns different results on different systems.  For example, the expression

	strcmp("a", "f")

returns -5 on some systems but -1 on others.  Note that the specification of
strcmp() in the LambdaMOO Programmer's Manual says that only the sign of the
result is guaranteed to be meaningful, so this change across implementations is
not, technically, a bug.

On the other hand, when people write MOO code that assumes more about the
result of strcmp() (like that it returns the difference between the ASCII
values of the first pair of unequal characters in the two strings), that MOO
code is not portable to some other systems.

There are two solutions to this difficulty:

	-- change the server code to always return -1, 0, or 1.
	-- change the server code to always return the difference between the
	   ASCII values of the first pair of unequal characters in the two
	   strings.

Since it is possible to write efficient MOO code to do something like the
latter, using the index() built-in function and any desired character order
(including ASCII), and since such a result has nothing to do with string
comparison, I intend to adopt the first solution above in the next server
release.

Comments?

	Pavel

From matt.ksu.ksu.edu!edwanji Tue Oct 27 14:28:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "14:13:45" "-0800" "Edwanji Lemorian" "edwanji@matt.ksu.ksu.edu " "<9210272213.AA17732@matt.ksu.ksu.edu>" "10" "Another built-in idea" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 14:28:54 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11857>; Tue, 27 Oct 1992 14:27:08 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11847>; Tue, 27 Oct 1992 14:25:34 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Tue, 27 Oct 1992 14:20:49 -0800
Received: from matt.ksu.ksu.edu ([129.130.12.2]) by alpha.xerox.com with SMTP id <11842>; Tue, 27 Oct 1992 14:13:39 PST
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA17732; Tue, 27 Oct 92 16:13:46 CST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002F3591
Message-ID: <9210272213.AA17732@matt.ksu.ksu.edu>
Date:	Tue, 27 Oct 1992 14:13:45 -0800
From:	edwanji@matt.ksu.ksu.edu (Edwanji Lemorian)
To:	moo-cows@parc.xerox.com
Subject: Another built-in idea

While we're talking about new built-ins, how about one that does
matching from a string to an object number. i.e. match_object("water",
player) returns the object number of whatever is aliased as "water" at
the location of player. The server already performs this task all the
time, so why not a command to do it? 
$whatever_utils:match() has always seemed a little over-blown for
something the server should be able to do more quickly from a builtin.
Just my thoughts.

--Eddie

From parc.xerox.com!pavel Tue Oct 27 14:56:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "14:47:26" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "15" "Re: Another built-in idea" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 14:56:17 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11835>; Tue, 27 Oct 1992 14:54:43 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11834>; Tue, 27 Oct 1992 14:53:07 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58375>; Tue, 27 Oct 1992 14:48:19 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11819>; Tue, 27 Oct 1992 14:47:45 PST
Received: by lambda.parc.xerox.com id <58375>; Tue, 27 Oct 1992 14:47:33 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F3678
In-Reply-to: <9210272213.AA17732@matt.ksu.ksu.edu>
Message-ID: <92Oct27.144733pst.58375@lambda.parc.xerox.com>
References: <9210272213.AA17732@matt.ksu.ksu.edu>
Date:	Tue, 27 Oct 1992 14:47:26 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	edwanji@matt.ksu.ksu.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: Another built-in idea

> Date:	Tue, 27 Oct 1992 14:13:45 -0800
> From:	edwanji@matt.ksu.ksu.edu (Edwanji Lemorian)
> 
> While we're talking about new built-ins, how about one that does
> matching from a string to an object number. i.e. match_object("water",
> player) returns the object number of whatever is aliased as "water" at
> the location of player. The server already performs this task all the
> time, so why not a command to do it? 

Actually, this is something I've been interested in removing from the server
for a long time.  I'd like to see all command-parsing done by the code in the
DB, instead, including the translation of names into objects.  The reason is
that in-DB code can do a much better job of context-dependent parsing.

	Pavel

From onet.edu!CAMP!seth Tue Oct 27 15:31:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "10:02:00" "-0800" "seth%CAMP@onet.edu" "seth%CAMP@onet.edu" nil "27" "Re: Another built-in idea" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 15:31:25 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11836>; Tue, 27 Oct 1992 15:31:02 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11831>; Tue, 27 Oct 1992 15:08:23 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Tue, 27 Oct 1992 15:03:45 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11831>; Tue, 27 Oct 1992 15:03:28 PST
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11819>; Tue, 27 Oct 1992 15:02:51 PST
Received: from CAMP.Onet.Edu ([141.110.32.5])  for Moo-Cows@Xerox.Com
	by oscsunb.osc.edu (5.65c+KVa/920330.1102) id AA19719; Tue, 27 Oct 1992 18:02:45 -0500
Received: from campgate.onet.edu by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA18481; Tue, 27 Oct 92 18:02:29 EST
Received: by campgate.onet.edu with Network-Courier
	id <2AEDCA7E@campgate.onet.edu>; Tue, 27 Oct 92 18:02:22
X-Mailer: Network Courier V2.1a
Encoding: 27 TEXT
X-NS-Transport-ID: 08002008D0FD002F36BB
Message-ID: <2AEDCA7E@campgate.onet.edu>
Date:	Tue, 27 Oct 1992 10:02:00 -0800
From:	seth%CAMP@onet.edu
To:	Moo-Cows.PARC@xerox.com
Subject: Re: Another built-in idea

> > Date: Tue, 27 Oct 1992 14:13:45 -0800
> > From:        edwanji@matt.ksu.ksu.edu (Edwanji Lemorian)
> > While we're talking about new built-ins, how about one that does
> > matching from a string to an object number. i.e. match_object("water",
> > player) returns the object number of whatever is aliased as "water" at
> > the location of player. The server already performs this task all the
> > time, so why not a command to do it? 

Pavel says:

> Actually, this is something I've been interested in removing from 
> the server for a long time.  I'd like to see all command-parsing 
> done by the code in the DB, instead, including the translation of 
> names into objects. The reason is that in-DB code can do a much 
> better job of context-dependent parsing.

Note that with the impending corification (in LambdaMOO) of the 
:contents() verb, if the server stopped doing the matching and left
it all to in-db matching, we'd be able to make metarooms (and other
pseudo-places) correctly.

For more information on this :contents() rambling (my latest Holy 
Crusade), bug me on LambdaMOO sometime or check out my long-winded
posts on *Core-DB-Issues.

Seth / Blackbriar


From wvnvaxa.wvnet.edu!UN032233 Tue Oct 27 21:19:17 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "20:09:03" "-0800" "Gilmore" "UN032233@wvnvaxa.wvnet.edu" nil "8" "Hacked clients" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Tue, 27 Oct 1992 21:19:15 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11872>; Tue, 27 Oct 1992 21:18:39 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11870>; Tue, 27 Oct 1992 21:15:24 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58377>; Tue, 27 Oct 1992 21:09:38 -0800
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <11869>; Tue, 27 Oct 1992 21:09:17 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQGNBMWMG09VUYIX@WVNVMS.WVNET.EDU>; Wed, 28 Oct 1992 00:09:03 EDT
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002F3BD2
Message-ID: <01GQGNBMWMG29VUYIX@WVNVMS.WVNET.EDU>
Date:	Tue, 27 Oct 1992 20:09:03 -0800
From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>
To:	moo-cows@parc.xerox.com
Subject: Hacked clients

In fact, there exists a hacked version of TinyTalk which allows one to use
emacs, or the editor of one's choice, to do one's editing in the MOO - when
you enter a MOO editor the editors are hacked to send a line begun with
'####', followed by some info for TinyTalk to use in invoking the editor.
Then, when emacs is exited, the resultant code is spit back to the MOO.  A
very nice setup...this was developed by Zytor on DalMOO.

Gilmore

From stony-brook.scrc.symbolics.com!yduJ Tue Oct 27 21:59:49 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "21:52:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "14" "Hacked clients" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29582>; Tue, 27 Oct 1992 21:59:47 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11876>; Tue, 27 Oct 1992 21:58:24 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11877>; Tue, 27 Oct 1992 21:56:32 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Tue, 27 Oct 1992 21:51:59 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11876>; Tue, 27 Oct 1992 21:51:29 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1165151; 28 Oct 1992 00:49:58-0500
X-NS-Transport-ID: 08002008D0FD002F3C13
In-Reply-to: <01GQGNBMWMG29VUYIX@WVNVMS.WVNET.EDU>
Message-ID: <19921028055206.4.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Tue, 27 Oct 1992 21:52:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	UN032233@wvnvaxa.wvnet.edu, moo-cows@parc.xerox.com
Subject: Hacked clients

    Date: Tue, 27 Oct 1992 23:09 EST
    From:	Gilmore <UN032233@wvnvaxa.wvnet.edu>

    In fact, there exists a hacked version of TinyTalk which allows one to use
    emacs, or the editor of one's choice, to do one's editing in the MOO - when
    you enter a MOO editor the editors are hacked to send a line begun with
    '####', followed by some info for TinyTalk to use in invoking the editor.
    Then, when emacs is exited, the resultant code is spit back to the MOO.  A
    very nice setup...this was developed by Zytor on DalMOO.

I'm curious.  What benefits does this have over any of the mud.el
variants?  They would seem to be superior in all ways; only if you
wanted a non-emacs editor could I imagine preferring your described
setup.

From magnolia.berkeley.edu!nj Wed Oct 28 00:02:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "27" "October" "1992" "23:54:00" "-0800" "Narciso Jaramillo" "nj@magnolia.berkeley.edu " nil "5" "Re:  Hacked clients" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 28 Oct 1992 00:02:38 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11879>; Wed, 28 Oct 1992 00:02:03 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11878>; Wed, 28 Oct 1992 00:00:22 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58379>; Tue, 27 Oct 1992 23:55:06 -0800
Received: from magnolia.Berkeley.EDU ([128.32.131.200]) by alpha.xerox.com with SMTP id <11878>; Tue, 27 Oct 1992 23:54:51 PST
Received: by magnolia.Berkeley.EDU (4.1/1.42)
	id AA22101; Tue, 27 Oct 92 23:54:00 PST
X-NS-Transport-ID: 08002008D0FD002F3CEA
Message-ID: <9210280754.AA22101@magnolia.Berkeley.EDU>
Date:	Tue, 27 Oct 1992 23:54:00 -0800
From:	nj@magnolia.berkeley.edu (Narciso Jaramillo)
To:	moo-cows@parc.xerox.com
Subject: Re:  Hacked clients

Even nicer is mud.el, which I believe is right on parcftp.xerox.com.  This
is a mud client implemented within Emacs, along with incredibly convenient
verb/description/property-editing functions.

nj

From wvnvaxa.wvnet.edu!FLORIAN Wed Oct 28 09:48:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "08:36:45" "-0800" "FLORIAN@wvnvaxa.wvnet.edu" "FLORIAN@wvnvaxa.wvnet.edu" "<01GQHDE62WB69X3IIY@WVNVMS.WVNET.EDU>" "15" "New LambdaCore" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 28 Oct 1992 09:48:25 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11981>; Wed, 28 Oct 1992 09:47:27 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11988>; Wed, 28 Oct 1992 09:43:32 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58382>; Wed, 28 Oct 1992 09:38:01 -0800
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <11973>; Wed, 28 Oct 1992 09:37:16 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQHDE62MO09X3IIY@WVNVMS.WVNET.EDU>; Wed, 28 Oct 1992 12:36:45 EDT
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002F4329
Message-ID: <01GQHDE62WB69X3IIY@WVNVMS.WVNET.EDU>
Date:	Wed, 28 Oct 1992 08:36:45 -0800
From:	FLORIAN@wvnvaxa.wvnet.edu
To:	moo-cows@parc.xerox.com
Subject: New LambdaCore

  Forgive my ignorance, but I've been kicking around a version of the
  1.7.0 server.  I am, however, using the old LambdaCore db(the new wasn't
  available when I obtained 1.7.0)...I have since done quite a bit of 
  building and coding on that db.  Is there any way to switch to the new
  lambdaCore db and retain all my work?  A conversion program or something?
  If not, thanks anyway. :)

*******************************************************************************
* Nicholas LaFlamme    *Florian@Wvnvms.Wvnet.edu *  You live and die for      *
* Vagrant, Programmer  *  Cis: [70742,1316]      *   freedom!                 *
* Poet, and Madman     *                         *       -Buzzkirk, Lensman   *
*******************************************************************************
                           But Dr. Pickering, in science as in morality the
                             Ends never justifies the means!.
                                         -The Docter (in Robot)

From allink.com!paul Wed Oct 28 10:20:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "10:06:47" "-0800" "paul reiber" "paul@allink.com " nil "20" "mud.el documentation" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 28 Oct 1992 10:20:08 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12004>; Wed, 28 Oct 1992 10:19:13 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11975>; Wed, 28 Oct 1992 10:17:44 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58384>; Wed, 28 Oct 1992 10:11:59 -0800
Received: from uu.psi.com ([136.161.128.3]) by alpha.xerox.com with SMTP id <11985>; Wed, 28 Oct 1992 10:08:37 PST
Received: from pluto.allink.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA14784; Wed, 28 Oct 92 13:07:37 -0500
Received: from rama.nynex.inm by allink.com (4.1/SMI-4.1)
	id AA13044; Wed, 28 Oct 92 13:06:47 EST
X-NS-Transport-ID: 08002008D0FD002F43E1
Message-ID: <9210281806.AA13044@allink.com>
Date:	Wed, 28 Oct 1992 10:06:47 -0800
From:	paul@allink.com (paul reiber)
To:	moo-cows@parc.xerox.com
Subject: mud.el documentation

Since my site's DNS is screwy, I've not been able to
use mud.el as a client to anywhere outside of the local
net.

So, even though I've been MOOing long enough to feel
comfortable starting my own MOOs for various purposes,
and even though I use gnu emacs daily, I'm still a
newbie to mud.el ...

Information about these `variants' of mud.el, and
what they get you, would be greatly appreciated.

Any introductory information anyone's produced re:
mud.el would also be appreciated.

And, to save yduJ an email, yeah, I'm getting what's
already on LambdaMOO righ after I hit the 'send'
button. :)

-Paul

From parc.xerox.com!pavel Wed Oct 28 11:12:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "11:02:29" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "22" "Bugs in released LambdaCore database" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 28 Oct 1992 11:12:08 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12002>; Wed, 28 Oct 1992 11:10:11 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11675>; Wed, 28 Oct 1992 11:07:52 PST
Received: by lambda.parc.xerox.com id <58381>; Wed, 28 Oct 1992 11:02:38 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F44F3
Message-ID: <92Oct28.110238pst.58381@lambda.parc.xerox.com>
Date:	Wed, 28 Oct 1992 11:02:29 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Bugs in released LambdaCore database

There have been a number of bugs discovered in the released LambdaCore
database.  You can fix them pretty easily, though, without having to fetch a
new version.

If you fetched `LambdaCore-25Oct92.db', then do this:

	@rmprop $login.monitor
	@rmverb $login:monitor
	@rmm 1-$ from *Site
	@renumber *Site
	@move #19 to #46
	@move #45 to #-1

If you fetched either `LambdaCore-25Oct92.db' or `LambdaCore-26Oct92.db', then
do this:

	;#19.messages = #19.messages_going = {}

The file `LambdaCore-28Oct92.db', now available on parcftp.xerox.com, has these
changes already incorporated.

	Pavel/Haakon

From parc.xerox.com!pavel Wed Oct 28 11:19:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "11:05:26" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "15" "Re: New LambdaCore" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 28 Oct 1992 11:19:42 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12012>; Wed, 28 Oct 1992 11:17:15 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12000>; Wed, 28 Oct 1992 11:15:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58386>; Wed, 28 Oct 1992 11:10:47 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12004>; Wed, 28 Oct 1992 11:08:12 PST
Received: by lambda.parc.xerox.com id <58386>; Wed, 28 Oct 1992 11:07:56 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F450C
In-Reply-to: <01GQHDE62WB69X3IIY@WVNVMS.WVNET.EDU>
Message-ID: <92Oct28.110756pst.58386@lambda.parc.xerox.com>
References: <01GQHDE62WB69X3IIY@WVNVMS.WVNET.EDU>
Date:	Wed, 28 Oct 1992 11:05:26 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	FLORIAN@wvnvaxa.wvnet.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: New LambdaCore

> Date:	Wed, 28 Oct 1992 08:36:45 -0800
> From:	FLORIAN@wvnvaxa.wvnet.edu
>
> Is there any way to switch to the new lambdaCore db and retain all my work?

Not really, except by using the @dump command (which may or may not even exist
in the old core...) to print out a script to recreate all of the objects you've
created.  You could then play that script in the new database.

On the other hand, if you've hacked on various bits of the core itself, then I
don't know of a nice way to save them.

Sorry,

	Pavel/Haakon

From parc.xerox.com!pavel Wed Oct 28 11:24:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "11:09:11" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "17" "Re: MOO and ascii files" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 28 Oct 1992 11:24:00 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12018>; Wed, 28 Oct 1992 11:23:19 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12006>; Wed, 28 Oct 1992 11:20:33 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58387>; Wed, 28 Oct 1992 11:15:31 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12018>; Wed, 28 Oct 1992 11:09:19 PST
Received: by lambda.parc.xerox.com id <58386>; Wed, 28 Oct 1992 11:09:16 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F4524
In-Reply-to: <9210281820.AA13134@allink.com>
Message-ID: <92Oct28.110916pst.58386@lambda.parc.xerox.com>
References: <9210281820.AA13134@allink.com>
Date:	Wed, 28 Oct 1992 11:09:11 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	paul@allink.com
cc:	moo-cows@parc.xerox.com
Subject: Re: MOO and ascii files

> Date:	Wed, 28 Oct 1992 10:20:15 -0800
> From:	paul@allink.com (paul reiber)
> 
> I need to provide a bidirectional mechanism
> between MOO and a standard UNIX directory
> hierarchy containing `straight ascii' files.
> 
> If anyone has undertaken something similar to this, or
> has any ideas as to how it could be implemented without
> modifications to the server, I'm all ears.

This will certainly require changes to the server, since there's currently no
way to access files from inside MOO code.

Enjoy,

	Pavel/Haakon

From uunet.uu.net!cbmvax!lynx!davidm Wed Oct 28 12:23:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "09:56:45" "-0800" "David Miller" "cbmvax!lynx!davidm@uunet.uu.net" nil "13" "Re: New LambdaCore.db Releases" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 28 Oct 1992 12:23:39 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12026>; Wed, 28 Oct 1992 12:21:36 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12010>; Wed, 28 Oct 1992 12:19:20 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58388>; Wed, 28 Oct 1992 12:11:28 -0800
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <12002>; Wed, 28 Oct 1992 12:11:04 PST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA14923; Wed, 28 Oct 92 15:11:08 -0500
Received: from cbmvax.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 151046.5333; Wed, 28 Oct 1992 15:10:46 EST
Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore 2/8/91)
	id AA16392; Wed, 28 Oct 92 13:04:58 EST
X-Mailer: ELM [version 2.3 PL11 913261353]
Content-Type: text
Content-Length: 401
X-NS-Transport-ID: 08002008D0FD002F46EE
Message-ID: <720295006.AA14259@lynx.commodore.com>
Date:	Wed, 28 Oct 1992 09:56:45 -0800
From:	David Miller <cbmvax!lynx!davidm@uunet.uu.net>
To:	moo-cows@parc.xerox.com (LambdaMOO Mailing List)
Subject: Re: New LambdaCore.db Releases
Reply-to: cbmvax!lynx!davidm@uunet.uu.net

Ok, I just grabbed the new LambdaCore.db from beta, now I have
a question:

How do I go about installing the new core?

Specifically, how do I upgrade the core without destroying all
of the non-core objects in the existing database?

DavidM	
-- 
DavidM			CATS - Commodore Applications and Technical Support
+1 215 431 9425		davidm@cbmvax.commodore.com
"Commodore Amiga 3000UX - Born to Run UNIX SVR4"

From nic.gac.edu!eostrom Wed Oct 28 12:43:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "12:33:52" "-0800" "Erik Ostrom" "eostrom@nic.gac.edu " nil "41" "mud.el documentation" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 28 Oct 1992 12:43:33 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12018>; Wed, 28 Oct 1992 12:42:14 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12011>; Wed, 28 Oct 1992 12:41:05 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58390>; Wed, 28 Oct 1992 12:36:22 -0800
Received: from gacvx1.gac.edu ([138.236.1.1]) by alpha.xerox.com with SMTP id <11944>; Wed, 28 Oct 1992 12:36:03 PST
Received: from dion (dion.gac.edu) by gacvx1.gac.edu with PMDF#10127; Wed, 28
 Oct 1992 14:37 CST
Received: by dion (NeXT-1.0 (From Sendmail 5.52)/GACnet-2.0-NeXT) id AA00336;
 Wed, 28 Oct 92 14:33:52 CST
X-NS-Transport-ID: 08002008D0FD002F478D
In-Reply-to: "paul reiber's message of Wed, 28 Oct 1992 10:06:47 PST
 <9210281806.AA13044@allink.com>"
Message-ID: <9210282033.AA00336@dion>
Date:	Wed, 28 Oct 1992 12:33:52 -0800
From:	eostrom@nic.gac.edu (Erik Ostrom)
To:	paul@allink.com
cc:	moo-cows@parc.xerox.com
Subject: mud.el documentation

   Date: 	Wed, 28 Oct 1992 10:06:47 PST
   From: paul@allink.com (paul reiber)

   Since my site's DNS is screwy, I've not been able to
   use mud.el as a client to anywhere outside of the local
   net.

Hm.  yduJ wrote a bunch of elisp to give mud.el the following
capability: If you can get to the outside world from M-x shell, you
can then use M-x mud-mode (or something) to tell mud.el to take over.
This works okay.  I thought this was in the version on parcftp;
I was wrong.  But that's America.

   So, even though I've been MOOing long enough to feel
   comfortable starting my own MOOs for various purposes,
   and even though I use gnu emacs daily, I'm still a
   newbie to mud.el ...

   Information about these `variants' of mud.el, and
   what they get you, would be greatly appreciated.

I worked on a variant for a while under various names (the variant,
not me). At the time I was trying to keep track of who had a copy, and
requested that people not give out extra copies; now I don't care any
more, but I no longer have a copy.  Perhaps someone should make a copy
available.  Um, I can't say offhand "what it gets you", because I just
don't remember.

   Any introductory information anyone's produced re:
   mud.el would also be appreciated.

Puff has written some documentation for my variant (something I never
did), which I imagine is useful if you have a copy of it.

   And, to save yduJ an email, yeah, I'm getting what's
   already on LambdaMOO righ after I hit the 'send'
   button. :)

   -Paul

--Erik/JF

From stony-brook.scrc.symbolics.com!yduJ Wed Oct 28 15:29:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "15:24:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "23" "mud.el documentation" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 28 Oct 1992 15:29:06 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11972>; Wed, 28 Oct 1992 15:28:32 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12042>; Wed, 28 Oct 1992 15:25:55 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58391>; Wed, 28 Oct 1992 15:20:53 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12037>; Wed, 28 Oct 1992 15:20:16 PST
Received: from AVOCADO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1165621; 28 Oct 1992 18:21:20-0500
X-NS-Transport-ID: 08002008D0FD002F4B13
In-Reply-to: <9210282033.AA00336@dion>
Message-ID: <19921028232411.6.YDUJ@AVOCADO.SCRC.Symbolics.COM>
Date:	Wed, 28 Oct 1992 15:24:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	eostrom@nic.gac.edu, paul@allink.com
cc:	moo-cows@parc.xerox.com
Subject: mud.el documentation

    Date: Wed, 28 Oct 1992 15:33 EST
    From:	eostrom@nic.gac.edu (Erik Ostrom)

       Date: 	Wed, 28 Oct 1992 10:06:47 PST
       From: paul@allink.com (paul reiber)

       Since my site's DNS is screwy, I've not been able to
       use mud.el as a client to anywhere outside of the local
       net.

    Hm.  yduJ wrote a bunch of elisp to give mud.el the following
    capability: If you can get to the outside world from M-x shell, you
    can then use M-x mud-mode (or something) to tell mud.el to take over.
    This works okay.  I thought this was in the version on parcftp;
    I was wrong.  But that's America.

I have just intalled pub/MOO/contrib/mud.el.yduJ on parcftp.  It dates
from May 1991 and may have suffered bitrot; I haven't tried to keep it
up to date.  I use one of the nameless JoeFeedback versions instead, and
no longer have the trouble where I had to telnet out to a gateway
machine before I could get to the mud, so I haven't been motivated to
keep my old hack running.  Feel free to take it over; it's a horrible
kluge, but it did indeed "work okay" back when I hacked it.

From parc.xerox.com!pavel Wed Oct 28 19:20:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "28" "October" "1992" "19:09:38" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "7" "Another LambdaCore.db note" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Wed, 28 Oct 1992 19:20:36 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12027>; Wed, 28 Oct 1992 19:19:50 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12052>; Wed, 28 Oct 1992 19:17:07 PST
Received: by lambda.parc.xerox.com id <58393>; Wed, 28 Oct 1992 19:09:42 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F4E81
Message-ID: <92Oct28.190942pst.58393@lambda.parc.xerox.com>
Date:	Wed, 28 Oct 1992 19:09:38 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Another LambdaCore.db note

If you picked up LambdaCore.db any time before this evening, then the initial
message you see when you first connect says that the message itself is stored
in $welcome_message.  This is not true; it is stored in $login.welcome_message
now.  The copy of LambdaCore.db on parcftp.xerox.,com has been updated with the
proper location in the message.

	Pavel/Haakon

From doc.ic.ac.uk!mjb Thu Oct 29 02:53:20 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "29" "October" "1992" "02:42:54" "-0800" "Matthew Jude Brown" "mjb@doc.ic.ac.uk" nil "15" "trouble compiling LambdaMOO 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 29 Oct 1992 02:53:10 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11526>; Thu, 29 Oct 1992 02:52:19 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11529>; Thu, 29 Oct 1992 02:50:13 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58396>; Thu, 29 Oct 1992 02:44:55 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11523>; Thu, 29 Oct 1992 02:44:37 PST
Received: from frigate.doc.ic.ac.uk ([129.31.81.223]) by alpha.xerox.com with SMTP id <11523>; Thu, 29 Oct 1992 02:43:27 PST
Received: from doc.ic.ac.uk by frigate.doc.ic.ac.uk 
          id <07191-0@frigate.doc.ic.ac.uk>; Thu, 29 Oct 1992 10:42:54 +0000
X-NS-Transport-ID: 08002008D0FD002F51FF
In-Reply-to: "asb@media-lab.media.mit.edu's message of Wed, 28 Oct 1992 15:22:38 PST <9210282322.AA02439@media-lab.mit.edu>"
Message-ID: <92Oct29.024327pst.11523@alpha.xerox.com>
Date:	Thu, 29 Oct 1992 02:42:54 -0800
From:	Matthew Jude Brown <mjb@doc.ic.ac.uk>
To:	asb@media-lab.media.mit.edu
cc:	MOO-cows.PARC@xerox.com
Subject: trouble compiling LambdaMOO 1.7.0

In your mail to moo-cows, you describe your problems compiling MOO
under SunOS 4.1 . Would you be interested in a ready-compiled version
of MOO for SunOS 4.1 and sparc? If you have FTP I could put it up
somewhere from where you could download it ...

I must confess your problems compiling seem very strange, perhaps
indicating that your system is not set up in a standard fashion?

-Morven@LambdaMOO

-- 
| Matthew J. Brown  | Dept. of Computing | If God intended for us to go to   |
| mjb@doc.ic.ac.uk  | Imperial College,  | lectures He wouldn't have created |
| mjb02@cc.ic.ac.uk | 180 Queen's Gate   | double-sided photocopiers.        |
| Morven on Lambda  | LONDON SW7 2AZ     |          -IC RagMag 1991/92       |

From ipac.caltech.edu!dave Thu Oct 29 11:18:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "29" "October" "1992" "11:02:58" "-0800" "dave@ipac.caltech.edu" "dave@ipac.caltech.edu" nil "9" "Re: trouble compiling LambdaMOO 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 29 Oct 1992 11:18:14 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11648>; Thu, 29 Oct 1992 11:16:58 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11629>; Thu, 29 Oct 1992 11:11:15 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58379>; Thu, 29 Oct 1992 11:05:30 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11631>; Thu, 29 Oct 1992 11:04:42 PST
Received: from ipac.caltech.edu ([131.215.139.35]) by alpha.xerox.com with SMTP id <11617>; Thu, 29 Oct 1992 11:03:03 PST
Return-Path: <dave@ipac.caltech.edu>
Received: from brando.ipac.caltech.edu
          by castor.ipac.caltech.edu (5.65-ir.030292)
          id AA19544; Thu, 29 Oct 92 11:03:01 -0800
Received: by brando.ipac.caltech.edu (c.090991)
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002F5A09
In-Reply-to: "<9210282322.AA02439@media-lab.mit.edu>; from \"asb@media-lab.media.mit.edu\" at Oct 28, 92 3:22 pm wrong"
Message-ID: <9210291902.AA00419@brando.ipac.caltech.edu>
Date:	Thu, 29 Oct 1992 11:02:58 -0800
From:	dave@ipac.caltech.edu
To:	asb@media-lab.media.mit.edu
cc:	MOO-cows.PARC@xerox.com
Subject: Re: trouble compiling LambdaMOO 1.7.0

Regarding trouble with memset in compiling lmoo:

We had a similar problem here, which we resolved by changing the appropriate
line in config.h (after running the configure script) to

#undef NDECL_MEMSET

Try that and see if it helps.


From xerox.com!PARC.xerox.com.PARC Thu Oct 29 18:02:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Thu" "29" "October" "1992" "17:50:07" "-0800" "Steven Charlton" "steven@cs.ualberta.ca" "<92Oct29.185024-0700.42311-1@scapa.cs.ualberta.ca>" "18" "Re: trouble compiling LambdaMOO 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 29 Oct 1992 18:02:49 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11685>; Thu, 29 Oct 1992 18:01:59 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11680>; Thu, 29 Oct 1992 17:57:56 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58398>; Thu, 29 Oct 1992 17:52:06 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11680>; Thu, 29 Oct 1992 17:51:35 PST
Received: from scapa.cs.ualberta.ca ([129.128.4.44]) by alpha.xerox.com with SMTP id <11680>; Thu, 29 Oct 1992 17:50:59 PST
Received: from silver-vly.cs.ualberta.ca by scapa.cs.ualberta.ca id <42311-1>; Thu, 29 Oct 1992 18:50:24 -0700
X-Mailer: ELM [version 2.4 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 561
X-NS-Transport-ID: 08002008D0FD002F629E
XNS-Originator: PARC.xerox.com.PARC@Xerox.com
Errors-to: PARC.xerox.com.PARC@xerox.com
Message-ID: <92Oct29.185024-0700.42311-1@scapa.cs.ualberta.ca>
Date:	Thu, 29 Oct 1992 17:50:07 -0800
From:	Steven Charlton <steven@cs.ualberta.ca>
Sender: <@scapa.cs.ualberta.ca:steven@cs.ualberta.CA>
To:	MOO-cows.PARC@xerox.com
Subject: Re: trouble compiling LambdaMOO 1.7.0

I have experienced the same problem. My system configuration follows:

	Sun 3/60   SunOS 4.1.1 
	gcc-2.2.2  (properly installed WITH fixincludes)
	
	NS_BSD and NP_TCP (ie. no changes to options.h)

Using the posted 
  #undef NDECL_MEMSET
fixes the first error, and adding
  #define volatile
  #define signed
fixes the second and subsequent errors.  After these fixes, things seem to
compile ok.  It even seems to run ok!  I'm not certain what effect #def'ing
volatile will have, but no big glareing error present themselves upon running
and connecting.
	Steve


From parc.xerox.com!pavel Thu Oct 29 18:16:52 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "29" "October" "1992" "18:07:06" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "20" "Re: trouble compiling LambdaMOO 1.7.0" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 29 Oct 1992 18:16:50 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11685>; Thu, 29 Oct 1992 18:15:26 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11691>; Thu, 29 Oct 1992 18:13:29 PST
Received: by lambda.parc.xerox.com id <58399>; Thu, 29 Oct 1992 18:07:18 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F62F4
In-Reply-to: <92Oct29.185024-0700.42311-1@scapa.cs.ualberta.ca>
Message-ID: <92Oct29.180718pst.58399@lambda.parc.xerox.com>
References: <92Oct29.185024-0700.42311-1@scapa.cs.ualberta.ca>
Date:	Thu, 29 Oct 1992 18:07:06 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	steven@cs.ualberta.ca
cc:	MOO-Cows@parc.xerox.com
Subject: Re: trouble compiling LambdaMOO 1.7.0

> Date:	Thu, 29 Oct 1992 17:50:07 -0800
> From:	Steven Charlton <steven@cs.ualberta.ca>
> 
>   #define volatile
>   #define signed
> fixes the second and subsequent errors.

It's probably better to say this, instead:

	#define volatile __volatile__
	#define signed __signed__

The problem is that `configure' thinks that it's necessary to use the
-traditional flag with GCC and that turns off support these two ANSI keywords.
However, GCC still supports its `hidden' aliases for the keywords, the ones
with double underscores before and after.

I'll have a fix in the code for these problems in the next release.

	Pavel

From media-lab.media.mit.edu!asb Sun Nov  1 12:16:26 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "12:06:28" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "25" "accidental recycling" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 12:16:17 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12075>; Sun, 1 Nov 1992 12:14:26 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12073>; Sun, 1 Nov 1992 12:11:10 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 1 Nov 1992 12:07:10 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11747>; Sun, 1 Nov 1992 12:06:45 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11747>; Sun, 1 Nov 1992 12:06:31 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA16127; Sun, 1 Nov 92 15:06:28 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD002F86DD
Message-ID: <9211012006.AA16127@media-lab.mit.edu>
Date:	Sun, 1 Nov 1992 12:06:28 -0800
From:	asb@media-lab.media.mit.edu
To:	moo-cows.PARC@xerox.com
cc:	MediaMOO@media-lab.media.mit.edu
Subject: accidental recycling


Typoman strikes again!  I was trying to recycle #106,
but accidentally typed #16.  Imagine the expression on
my face when I saw:

Generic Large-Capacity Mail Recipient (#16) recycled.

(Another reminder why you should hang around in a mortal character
whenever possible!)

A couple questions:

I assume there's no way to get #16 back.  (The words "irrevocably
and irretrievably" in the documentation tipped me off...)
How can I reload it from the backup or from LambdaCore?

Is there any way to allow things to be rescued from the trash
for a period of time?  Why not put things in a trash can and
then schedule how often the trash is emptied?  (There could be
an @recycle-immediately or something similar if an object was somehow
causing problems.)

Thanks!

-- fumble-fingers-Bruckman

From media-lab.media.mit.edu!asb Sun Nov  1 12:30:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "12:25:03" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "7" "The Body Bag" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 12:30:48 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12078>; Sun, 1 Nov 1992 12:29:28 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11743>; Sun, 1 Nov 1992 12:27:31 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 1 Nov 1992 12:26:01 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11743>; Sun, 1 Nov 1992 12:25:48 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12071>; Sun, 1 Nov 1992 12:25:05 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA16691; Sun, 1 Nov 92 15:25:04 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD002F8704
Message-ID: <9211012025.AA16691@media-lab.mit.edu>
Date:	Sun, 1 Nov 1992 12:25:03 -0800
From:	asb@media-lab.media.mit.edu
To:	moo-cows.PARC@xerox.com
Subject: The Body Bag


A quick question:

If sleeping players are in the coat closet,
what is the body bag for?

-- Amy

From stony-brook.scrc.symbolics.com!yduJ Sun Nov  1 15:03:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "14:36:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "7" "The Body Bag" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 15:02:56 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12123>; Sun, 1 Nov 1992 15:01:22 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12120>; Sun, 1 Nov 1992 14:59:44 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 1 Nov 1992 14:55:28 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12115>; Sun, 1 Nov 1992 14:55:02 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12115>; Sun, 1 Nov 1992 14:54:23 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1167352; 1 Nov 1992 17:35:55-0500
X-NS-Transport-ID: 08002008D0FD002F88A4
In-Reply-to: <9211012025.AA16691@media-lab.mit.edu>
Message-ID: <19921101223601.3.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Sun, 1 Nov 1992 14:36:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	asb@media-lab.media.mit.edu, moo-cows.PARC@xerox.com
Subject: The Body Bag

Sleeping players aren't in the closet, they're in the body bag.  They
used to be in the closet, but when a mud gets large, the amount of time
it takes to transmit noises made in the closet to the sleeping players
(which noise is just discarded, but *does* make the relevant verb calls
first) begins to make it so that all noisemaking tasks run out of
ticks/seconds.  Players are transferred to the body bag from the closet
upon disconnection, and to the closet again upon connection.

From xerox.com!parc.xerox.com.PARC Sun Nov  1 16:27:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "16:16:54" "-0800" "Byron Montgomerie" "byron@cs.mun.ca" nil "10" "" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 16:27:50 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12144>; Sun, 1 Nov 1992 16:27:10 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12140>; Sun, 1 Nov 1992 16:25:46 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Sun, 1 Nov 1992 16:20:53 -0800
Received: from garfield.cs.mun.ca ([134.153.1.1]) by alpha.xerox.com with SMTP id <12138>; Sun, 1 Nov 1992 16:20:09 PST
Received: by garfield.cs.mun.ca id <45079>; Sun, 1 Nov 1992 20:47:06 -0330
X-NS-Transport-ID: 08002008D0FD002F8971
Message-ID: <92Nov1.204706nst.45079@garfield.cs.mun.ca>
Date:	Sun, 1 Nov 1992 16:16:54 -0800
From:	Byron Montgomerie <byron@cs.mun.ca>
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com

Hmmm, how does one activate the body bag thing?  Sleeping players are shown as 
being in the first room on my copy of the core.  Oct 25, 1992 version.
 
 Byron...
 ___________________________________________________________________________
|     ///    "Byron Montgomerie"  Internet: byron@odie.cs.mun.ca       ///  |
| \\\///      "Does anybody here remember Vera Lynn?               \\\///   |
|  \///        How she said that we would meet again,               \///    |
|  Amiga       some sunny day..." -- Pink Floyd --                 Amiga    |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From stony-brook.scrc.symbolics.com!yduJ Sun Nov  1 17:06:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "17:00:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "10" "" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 17:06:51 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12148>; Sun, 1 Nov 1992 17:06:15 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12152>; Sun, 1 Nov 1992 17:04:39 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58374>; Sun, 1 Nov 1992 17:00:19 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12149>; Sun, 1 Nov 1992 16:59:51 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1167408; 1 Nov 1992 20:00:46-0500
X-NS-Transport-ID: 08002008D0FD002F89D5
In-Reply-to: <92Nov1.204706nst.45079@garfield.cs.mun.ca>
Message-ID: <19921102010051.9.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Sun, 1 Nov 1992 17:00:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	byron@cs.mun.ca, moo-cows@parc.xerox.com

I figured it out.  The verbs are all deleted from #11 on LambdaMOO
during core extraction, including :disfunc and :enterfunc, which make it
work.  I'm updating the core extraction mechanism on LambdaMOO to only
delete VR verbs on Lambda's coat closet instead of all verbs wholesale,
the body bag should work properly in new cores.

To update your existing one, @property $player_start.body_bag <$limbo>
(whatever number that is, #17 I think), upload the definitions of
#11:disfunc and :enterfunc into your MOO.  (I'd reproduce them here but
it's a minor pain and I'm lazy.)

From wvnvaxa.wvnet.edu!FLORIAN Mon Nov  2 15:11:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "2" "November" "1992" "14:57:23" "-0800" "FLORIAN@wvnvaxa.wvnet.edu" "FLORIAN@wvnvaxa.wvnet.edu" nil "11" "Obvious_exits" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 2 Nov 1992 15:11:36 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12259>; Mon, 2 Nov 1992 15:09:46 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12101>; Mon, 2 Nov 1992 15:04:58 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 2 Nov 1992 14:58:19 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12081>; Mon, 2 Nov 1992 14:57:58 PST
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12085>; Mon, 2 Nov 1992 14:57:26 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GQOO4RB8J49X49N7@WVNVMS.WVNET.EDU>; Mon, 2 Nov 1992 17:57:23 EST
X-VMS-To: IN%"MOO-Cows@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD002F9D22
Message-ID: <01GQOO4RB8J69X49N7@WVNVMS.WVNET.EDU>
Date:	Mon, 2 Nov 1992 14:57:23 -0800
From:	FLORIAN@wvnvaxa.wvnet.edu
To:	MOO-Cows.PARC@xerox.com
Subject: Obvious_exits

  I can't seem to get Obvious_exits to work wit version 1.7.0
  and the 28Oct92 db.  I was wondering if anyone had any input on this.

*******************************************************************************
* Nicholas LaFlamme    *Florian@Wvnvms.Wvnet.edu *  You live and die for      *
* Vagrant, Programmer  *  Cis: [70742,1316]      *   freedom!                 *
* Poet, and Madman     *                         *       -Buzzkirk, Lensman   *
*******************************************************************************
                           But Dr. Pickering, in science as in morality the
                             Ends never justifies the means!.
                                         -The Docter (in Robot)

From stony-brook.scrc.symbolics.com!yduJ Mon Nov  2 15:46:33 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "2" "November" "1992" "15:39:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "7" "Obvious_exits" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 2 Nov 1992 15:46:25 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12261>; Mon, 2 Nov 1992 15:45:53 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12251>; Mon, 2 Nov 1992 15:43:18 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58376>; Mon, 2 Nov 1992 15:36:46 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12245>; Mon, 2 Nov 1992 15:36:26 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12244>; Mon, 2 Nov 1992 15:35:45 PST
Received: from AVOCADO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1167947; 2 Nov 1992 18:36:37-0500
X-NS-Transport-ID: 08002008D0FD002F9E0D
In-Reply-to: <01GQOO4RB8J69X49N7@WVNVMS.WVNET.EDU>
Message-ID: <19921102233939.9.YDUJ@AVOCADO.SCRC.Symbolics.COM>
Date:	Mon, 2 Nov 1992 15:39:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	FLORIAN@wvnvaxa.wvnet.edu, MOO-Cows.PARC@xerox.com
Subject: Obvious_exits

As I recall, not much has been done with obvious exits; it's mostly just
a substrate for future expansions.  It doesn't, for example,
automatically put a list of obvious exits in room descriptions.

Judy Anderson yclept yduJ    yduJ@symbolics.com   'yduJ' rhymes with 'fudge'
    [ LambdaMOO is lambda.parc.xerox.com 8888 / 13.2.116.36 8888 ]
       Join the League for Programming Freedom, lpf@uunet.uu.net

From media-lab.media.mit.edu!asb Wed Nov  4 18:29:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "4" "November" "1992" "18:15:08" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" "<9211050215.AA05971@media-lab.mit.edu>" "11" "dash and underscore" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Wed, 4 Nov 1992 18:29:03 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12804>; Wed, 4 Nov 1992 18:27:02 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12802>; Wed, 4 Nov 1992 18:21:58 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 4 Nov 1992 18:16:29 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12794>; Wed, 4 Nov 1992 18:16:00 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12794>; Wed, 4 Nov 1992 18:15:10 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA05971; Wed, 4 Nov 92 21:15:09 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD002FCD54
Message-ID: <9211050215.AA05971@media-lab.mit.edu>
Date:	Wed, 4 Nov 1992 18:15:08 -0800
From:	asb@media-lab.media.mit.edu
To:	moo-cows.PARC@xerox.com
Subject: dash and underscore


Is there a reason that some functions have underscores and 
some use dashes?  For example:

@make-player
set_player_flag

It looks to me like almost everything has underscores, but
a lisp hacker must've written a few functions... :-)

-- Amy

From parc.xerox.com!pavel Wed Nov  4 19:02:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "4" "November" "1992" "18:52:23" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "22" "Re: dash and underscore" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 4 Nov 1992 19:02:39 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12814>; Wed, 4 Nov 1992 19:01:46 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12824>; Wed, 4 Nov 1992 19:00:04 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 4 Nov 1992 18:53:43 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12814>; Wed, 4 Nov 1992 18:53:20 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12813>; Wed, 4 Nov 1992 18:52:48 PST
Received: by lambda.parc.xerox.com id <58372>; Wed, 4 Nov 1992 18:52:37 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002FCDE6
In-Reply-to: <9211050215.AA05971@media-lab.mit.edu>
Message-ID: <92Nov4.185237pst.58372@lambda.parc.xerox.com>
References: <9211050215.AA05971@media-lab.mit.edu>
Date:	Wed, 4 Nov 1992 18:52:23 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	asb@media-lab.media.mit.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: dash and underscore

> Date:	Wed, 4 Nov 1992 18:15:08 -0800
> From:	asb@media-lab.media.mit.edu
> 
> Is there a reason that some functions have underscores and 
> some use dashes?  For example:
> 
> @make-player
> set_player_flag
> 
> It looks to me like almost everything has underscores, but
> a lisp hacker must've written a few functions... :-)

My rule is that I always use underscore if the verb/function is typically to be
called from MOO code and hyphen if the verb is typically only called from the
command line.  The idea is that underscore doesn't require any quoting in MOO
verb names and hyphen is easier to type.

It is also the case that Lisp hackers have written a fair amount of the code in
the MOO server and LambdaCore database, since both yduJ and I have longish
histories as Lispers, but I don't think that's related to this issue... :-)

	Pavel/Haakon

From stony-brook.scrc.symbolics.com!yduJ Wed Nov  4 19:09:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "4" "November" "1992" "19:03:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "6" "dash and underscore" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 4 Nov 1992 19:09:56 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12827>; Wed, 4 Nov 1992 19:08:48 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12826>; Wed, 4 Nov 1992 19:07:15 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 4 Nov 1992 19:03:49 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12814>; Wed, 4 Nov 1992 19:03:07 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12829>; Wed, 4 Nov 1992 19:02:29 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1169307; 4 Nov 1992 22:03:07-0500
X-NS-Transport-ID: 08002008D0FD002FCE1A
In-Reply-to: <9211050215.AA05971@media-lab.mit.edu>
Message-ID: <19921105030327.4.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Wed, 4 Nov 1992 19:03:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	asb@media-lab.media.mit.edu, moo-cows.PARC@xerox.com
Subject: dash and underscore

Inside code, dashes will be taken as minus-signs.  So underscores must
be used in identifier names.  In commands, characters can have whatever
meaning we damn well please.  Dashes are more convenient, and thus are
used more often in command names.  You quoted one command name
(@make-player) and one function name (set_player_flag).  Consider the
contexts; you'll see it's fairly consistent.

From nova.decio.nd.edu!jonathan Thu Nov  5 14:13:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Thu" "5" "November" "1992" "13:59:52" "-0800" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " "<9211052159.AA09618@nova.decio.nd.edu>" "9" "Moo on NeXT" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Thu, 5 Nov 1992 14:13:06 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12182>; Thu, 5 Nov 1992 14:11:23 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12102>; Thu, 5 Nov 1992 14:08:13 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 5 Nov 1992 14:05:36 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12102>; Thu, 5 Nov 1992 14:04:58 PST
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <12240>; Thu, 5 Nov 1992 14:01:37 PST
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09618; Thu, 5 Nov 92 16:59:53 EST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002FE05A
Message-ID: <9211052159.AA09618@nova.decio.nd.edu>
Date:	Thu, 5 Nov 1992 13:59:52 -0800
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	MOO-Cows@xerox.com (Moo-Cows)
Subject: Moo on NeXT


Anyone who has run the MOO 1.7.0 on a NeXT machine without getting 
vm_allocate errors please email me. I am trying to isolate the cause.

-- 
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -

From parc.xerox.com!pavel Thu Nov  5 14:46:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "5" "November" "1992" "14:34:59" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "13" "Re: Moo on NeXT" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29582>; Thu, 5 Nov 1992 14:46:23 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12187>; Thu, 5 Nov 1992 14:44:37 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12248>; Thu, 5 Nov 1992 14:40:37 PST
Received: by lambda.parc.xerox.com id <58372>; Thu, 5 Nov 1992 14:35:12 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002FE13E
In-Reply-to: <9211052159.AA09618@nova.decio.nd.edu>
Message-ID: <92Nov5.143512pst.58372@lambda.parc.xerox.com>
References: <9211052159.AA09618@nova.decio.nd.edu>
Date:	Thu, 5 Nov 1992 14:34:59 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	jonathan@nova.decio.nd.edu
cc:	MOO-Cows@parc.xerox.com
Subject: Re: Moo on NeXT

[I'm responding to Jonathan on the list since others might benefit from the
answer.]

I believe that somebody else found that these errors (indicating that the
server has used up more memory than the OS is willing to give it) were caused
by defining LOG_COMMANDS in options.h and then using a long $dump_interval (24
hours).  Since the server is then keeping (in memory) a copy of every single
command typed by any player over a 24-hour period, each one with a ~20
character time stamp on the front, this appeared to be a good way to run out of
memory.  If this describes your set-up, I'd recommend turning off LOG_COMMANDS,
reducing $dump_interval to something like 3600 (one hour), or both.

	Pavel/Haakon

From media-lab.media.mit.edu!asb Thu Nov  5 15:28:01 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Thu" "5" "November" "1992" "15:20:15" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" "<9211052320.AA08392@media-lab.mit.edu>" "13" "porting an object between MOOs" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Thu, 5 Nov 1992 15:27:56 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12253>; Thu, 5 Nov 1992 15:26:30 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12256>; Thu, 5 Nov 1992 15:24:11 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 5 Nov 1992 15:21:06 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11833>; Thu, 5 Nov 1992 15:20:44 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11823>; Thu, 5 Nov 1992 15:20:17 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA08392; Thu, 5 Nov 92 18:20:15 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD002FE247
Message-ID: <9211052320.AA08392@media-lab.mit.edu>
Date:	Thu, 5 Nov 1992 15:20:15 -0800
From:	asb@media-lab.media.mit.edu
To:	moo-cows.PARC@xerox.com
Subject: porting an object between MOOs


Maybe I didn't phrase this question well before....

What is the best way to port objects between MOOs?
I want to restore something I recycled by accident from an old db file.
I'm really tempted to bring the MOO down for a couple minutes
and edit the database file directly, but my common sense tells
me that's not a good idea!  :-)

Do I need to just examine the object and hand copy it, one 
verb at a time?  Is there a better way?

-- Amy

From nova.decio.nd.edu!jonathan Thu Nov  5 15:40:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "5" "November" "1992" "15:31:56" "-0800" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " nil "137" "Re: Moo on NeXT" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Thu, 5 Nov 1992 15:40:12 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12273>; Thu, 5 Nov 1992 15:39:45 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12267>; Thu, 5 Nov 1992 15:37:52 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 5 Nov 1992 15:34:59 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11823>; Thu, 5 Nov 1992 15:34:39 PST
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <12254>; Thu, 5 Nov 1992 15:33:41 PST
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09977; Thu, 5 Nov 92 18:31:57 EST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002FE290
In-Reply-to: "<92Nov5.143512pst.58372@lambda.parc.xerox.com>; from \"Pavel Curtis\" at Nov 5, 92 2:34 pmov 199"
Message-ID: <9211052331.AA09977@nova.decio.nd.edu>
Date:	Thu, 5 Nov 1992 15:31:56 -0800
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	MOO-Cows@xerox.com (Moo-Cows)
Subject: Re: Moo on NeXT

> I believe that somebody else found that these errors (indicating that the
> server has used up more memory than the OS is willing to give it) were caused
> by defining LOG_COMMANDS in options.h and then using a long $dump_interval (24
> hours).  Since the server is then keeping (in memory) a copy of every single
> command typed by any player over a 24-hour period, each one with a ~20
>character time stamp on the front, this appeared to be a good way to run out of
>memory.  If this describes your set-up, I'd recommend turning off LOG_COMMANDS,
> reducing $dump_interval to something like 3600 (one hour), or both.

I have turned off command logging and dump every 4 hours or less. This has
generally decreased the number of frequency of the crashes but has not
fixed the problem. Today, a crash happened 5 hrs after I restarted the
server. The Moo is started by a "Reinit" csh script file on a 68040 NeXT
slab with 16mb of memory and a swapfile on a drive with 80MB free. There
are only two users - one console and one tty. Crashes can occour at any
time with no prediction. They can occour using the KILL -USR1 command to
make a database dump or by themselves. Sometimes, one can get a crash
after allocating a large amount of memory such as for @display on a large
(help DB) for example but it is not repeatable. The following is my reinit
code: (its not pretty but it does work). The crashes can happen when one
or more people are using the MOO or when a dump is requested.

--CUT HERE--
#! /bin/csh
# This file is used to bring up the Moo or down it and restart
# It checks for a DUMP file and both DBASE and DBASE.ZIP files.
# It can  be used interactively or in a crontab.

nice +20
cd /jonathan/Moo
set dbase=void
set dump=dump
set kernel=mookernd
set moopid=`ps -cx | grep "$kernel"`

if ( $#moopid != 0 ) then
  echo "Void is running. Bringing it down at `date`"
  echo "`date`: Sent shutdown (KILL -USR1) $moopid[1]" >> $dbase.log
  kill -USR1 $moopid[1]
  while ( $#moopid != 0 )
    sleep 60
    echo "  Waiting for MUD to dump at `date` ..."
    set moopid=`ps -cx | grep "$kernel"`
  end
else
  echo "Void is not running at `date`"
endif

# Check for a dump file (if the moo was up it should have one)
if ( -r $dump ) then
  set line=`tail -1 $dump`
  if ( "$line" =~ *suspended* ) then
    echo "  Valid $dump - moving to $dbase"
    mv -f $dump $dbase
    echo "  Creating backup zip file of $dbase ...."
    /NovaBin/zip $dbase.zip $dbase
    echo "  Compressing log file ..."
    cat $dbase.log >> $dbase.log.all
    cat /dev/null > $dbase.log
    tail -1000 $dbase.log.all > $dbase.log.tmp
    mv -f $dbase.log.tmp $dbase.log.all
    echo "  Sending database to IRISHMVS storage account ..."
    set ftp_cmd	= "ftp -n backupsite"
    set total_size  = `cat void.zip void.log.all | wc -c`
    echo "    Total transfer size is $total_size bytes."
    if ( $total_size < 100000 ) then
      echo "      UH - I DON'T THINK THIS IS CORRECT LESS THAN 1MB"
    else
      if ( $total_size >= 5000000 ) then
        echo "      OH SMEG - TOTAL SIZE TOO LARGE TO BACKUP TO ACCOUNT"
      else
        echo "user me password"       > ftp.get
        echo "bin"                    >> ftp.get
        echo "delete void.zip"	      >> ftp.get
        echo "send void.zip"          >> ftp.get
        echo "delete void.log.all"    >> ftp.get
        echo "send void.log.all"      >> ftp.get
        echo "bye"                    >> ftp.get
        $ftp_cmd < ftp.get
        rm -f ftp.get
        echo "    Complete."
      endif
    endif
  else
    echo "  WARNING: $dump not valid. Moving to $dump.BAD"
    mv -f $dump $dump.BAD
  endif
else
  echo "  No $dump file found."
endif

# Now lets bring thevoid up

echo "RESTART $dbase at `date`" 

# Check for a database file - should be one from dump but in case
# the dump was bad we need to have a way of getting the old version

if (! -r $dbase) then
  if (-r $dbase.zip) then
    echo "  Can't find $dbase, unzipping $dbase.zip ..."
    /NovaBin/unzip $dbase.zip
  else
    echo "  Can't find $dbase or $dbase.zip - aborting"
    exit 1
  endif
else
  echo "  Found $dbase."
endif

set line=`tail -1 $dbase`
if ( "$line" =~ *suspended* ) then
  echo "  Checking: $dbase is valid."
else
  echo "  WARNING: Problem with $dbase - renaming and aborting!"
  mv -f $dbase $dbase.BAD
  exit 1
endif

echo `date`: RESTARTED >> $dbase.log
echo -n "  Starting Moo process as "
$kernel $dbase $dump >>& $dbase.log &
echo "COMPLETED restart at `date`"
exit 0

---CUT HERE---

By the way, improvements to the above are welcome. It is run every morning
by cron at 5am and can be run at any time by myself. It works great for me.

How long before the disk version Pavel? <grin> Maybe this will solve it!

-- 
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -

From magnolia.berkeley.edu!nj Thu Nov  5 15:49:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "5" "November" "1992" "15:38:20" "-0800" "Narciso Jaramillo" "nj@magnolia.berkeley.edu " nil "60" "Re:  porting an object between MOOs" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Thu, 5 Nov 1992 15:48:59 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12277>; Thu, 5 Nov 1992 15:47:33 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12254>; Thu, 5 Nov 1992 15:45:35 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 5 Nov 1992 15:42:01 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12194>; Thu, 5 Nov 1992 15:40:46 PST
Received: from magnolia.Berkeley.EDU ([128.32.131.200]) by alpha.xerox.com with SMTP id <12266>; Thu, 5 Nov 1992 15:39:48 PST
Received: by magnolia.Berkeley.EDU (4.1/1.42)
	id AA08543; Thu, 5 Nov 92 15:38:20 PST
X-NS-Transport-ID: 08002008D0FD002FE2AD
Message-ID: <9211052338.AA08543@magnolia.Berkeley.EDU>
Date:	Thu, 5 Nov 1992 15:38:20 -0800
From:	nj@magnolia.berkeley.edu (Narciso Jaramillo)
To:	asb@media-lab.media.mit.edu, moo-cows.PARC@xerox.com
Subject: Re:  porting an object between MOOs

I wrote a @dump_object macro that will print out a script enabling you
to create a (nearly) identical copy of an object on another MOO.  (I
gather that there's something like this in the 1.7 core, but we were
running an old version.)  Of course, the script assumes the existence
on the target MOO of all objects and verbs that the dumped object
refers to; the script can be edited by hand to fix the parent number,
etc.  When run on the new MOO, the clone object will be owned by the
person running the script and will be in that person's inventory;
also, the script can't set any `c' properties (unless you're a wizard,
I guess).  Other than that, the new object should be pretty much
identical.

No guarantees expressed or implied; `it works for me, occasionally.'

.program me:@dump_object
"Prints out a script that could be used to recreate the object in another";
"MOO.  Assumes the parent number is the same; the owner will be whoever";
"runs the script, and the location will be in that player's inventory";
"rather than wherever it is in the source MOO.  Programmers and wizards";
"cannot be dumped.";
if (!valid(dobj))
  player:tell("Not a valid object.");
elseif (dobj.owner != player)
  player:tell("Can't dump an object you don't own.");
elseif (dobj.wizard || dobj.programmer)
  player:tell("Can't dump programmers or wizards.");
else
  player:tell("\"***Start of script to recreate object ", dobj.name, ".");
  player:tell(";if (!(\"_recreating\" in properties(player))) add_property(player, \"_recreating\", #-1, {player, \"\"}); endif");
  player:tell(";player._recreating = create(", parent(dobj), ")");
  player:tell(";move(player._recreating, player)");
  player:tell(";player._recreating.name = \"", dobj.name, "\"");
  player:tell(";player._recreating.r = ", dobj.r);
  player:tell(";player._recreating.w = ", dobj.w);
  for i in ($object_utils:all_properties(dobj))
    if (!(i in {"owner", "location", "programmer", "wizard"}))
      pperms = property_info(dobj, i)[2];
      if (i in properties(dobj))
        player:tell(";add_property(player._recreating, \"", i, "\", ", $string_utils:from_value(dobj.(i), 1), ", {player, \"", pperms, "\"})");
      else
        player:tell(";set_property_info(player._recreating, \"", i, "\", {player, \"", pperms, "\"})");
        player:tell(";player._recreating.", i, " = ", $string_utils:from_value(dobj.(i), 1));
      endif
    endif
    if (ticks_left() < 20 || seconds_left() < 2)
      suspend(1);
    endif
  endfor
  for i in (verbs(dobj))
    player:tell(";add_verb(player._recreating, ", $string_utils:from_value(verb_info(dobj, i), 1), ", ", $string_utils:from_value(verb_args(dobj, i), 1), ")");
    if (ticks_left() < 20 || seconds_left() < 2)
      suspend(1);
    endif
    player:tell(";set_verb_code(player._recreating, \"", i, "\", ", $string_utils:from_value(verb_code(dobj, i), 1), ")");
    if (ticks_left() < 20 || seconds_left() < 2)
      suspend(1);
    endif
  endfor
  player:tell("\"***End of script to recreate object ", dobj.name, ".");
endif

From parc.xerox.com!pavel Thu Nov  5 15:58:23 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "5" "November" "1992" "15:50:26" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "13" "Re: porting an object between MOOs" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Thu, 5 Nov 1992 15:58:15 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12284>; Thu, 5 Nov 1992 15:55:47 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12278>; Thu, 5 Nov 1992 15:54:04 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 5 Nov 1992 15:51:46 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12269>; Thu, 5 Nov 1992 15:51:19 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12194>; Thu, 5 Nov 1992 15:50:41 PST
Received: by lambda.parc.xerox.com id <58372>; Thu, 5 Nov 1992 15:50:28 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002FE2F3
In-Reply-to: <9211052320.AA08392@media-lab.mit.edu>
Message-ID: <92Nov5.155028pst.58372@lambda.parc.xerox.com>
References: <9211052320.AA08392@media-lab.mit.edu>
Date:	Thu, 5 Nov 1992 15:50:26 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	asb@media-lab.media.mit.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: porting an object between MOOs

> Date:	Thu, 5 Nov 1992 15:20:15 -0800
> From:	asb@media-lab.media.mit.edu
> 
> What is the best way to port objects between MOOs?
> I want to restore something I recycled by accident from an old db file.

The @dump command will do most of the work for you; type `help @dump' for
details.  It will print out a list of commands to recreate the object.  You
somehow capture those commands and then replay them into the new MOO.  You'll
want to check them over before just dumping them into the new MOO; they usually
need a small amount of hand editing.

	Pavel

From terra.risc.uni-linz.ac.at!staferne Thu Nov 12 01:42:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "12" "November" "1992" "02:32:47" "-0800" "staferne@terra.risc.uni-linz.ac.at" "staferne@terra.risc.uni-linz.ac.at" nil "11" "Re: still having trouble compiling moo 1.7 on a Sun SPARCstation ipc" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Thu, 12 Nov 1992 01:42:06 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11552>; Thu, 12 Nov 1992 01:40:06 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11543>; Thu, 12 Nov 1992 01:37:18 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 12 Nov 1992 01:35:03 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11539>; Thu, 12 Nov 1992 01:34:46 PST
Received: from terra.risc.uni-linz.ac.at ([140.78.144.2]) by alpha.xerox.com with SMTP id <11539>; Thu, 12 Nov 1992 01:34:11 PST
Received: by terra.risc.uni-linz.ac.at (AIX 3.2/UCB 5.64/4.03)
          id AA12493; Thu, 12 Nov 1992 10:32:47 GMT
X-NS-Transport-ID: 08002008D0FD003059CC
Message-ID: <9211121032.AA12493@terra.risc.uni-linz.ac.at>
Date:	Thu, 12 Nov 1992 02:32:47 -0800
From:	staferne@terra.risc.uni-linz.ac.at
To:	moo-cows.PARC@xerox.com
Subject: Re: still having trouble compiling moo 1.7 on a Sun SPARCstation ipc



>I'm still having trouble compiling LambdaMOO on the Sun
>SPARCstation ipc in our lab.  One possible explanation is that
>our gcc is version 1.39.  Here are all the changes I made:

I think you should get the latest version of gcc. Those versions before 2.0
very rather buggy. 

Stefan Taferner
staferne@risc.uni-linz.ac.at

From cheshire.oxy.edu!t_pascal Thu Nov 12 20:33:50 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "12" "November" "1992" "20:26:24" "-0800" "C. Regis Wilson" "t_pascal@cheshire.oxy.edu " nil "20" "@players" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29592>; Thu, 12 Nov 1992 20:33:47 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12274>; Thu, 12 Nov 1992 20:33:17 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12269>; Thu, 12 Nov 1992 20:29:24 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 12 Nov 1992 20:27:17 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12269>; Thu, 12 Nov 1992 20:26:54 PST
Received: from gate.oxy.edu ([134.69.1.2]) by alpha.xerox.com with SMTP id <12269>; Thu, 12 Nov 1992 20:26:27 PST
Received: from cheshire.oxy.edu by gate.oxy.edu (4.0/SMI-4.0)
	id AA21663; Thu, 12 Nov 92 20:26:37 PST
Received: by cheshire.oxy.edu (4.1/SMI-4.1)
	id AA02245; Thu, 12 Nov 92 20:26:24 PST
X-NS-Transport-ID: 08002008D0FD0030706D
Message-ID: <9211130426.AA02245@cheshire.oxy.edu>
Date:	Thu, 12 Nov 1992 20:26:24 -0800
From:	t_pascal@cheshire.oxy.edu (C. Regis Wilson)
To:	moo-cows.PARC@xerox.com
Subject: @players


>help @players

Syntax:  @players [with objects]

Hmmm... what *does* this do, anyway?





:)  I have no idea, just from typing it, and the code doesn't seem to
explain its purpose.  (I can see what it's doing, but not why :)

---------
T. Pascal, King of Pascal    |  "As between mice and men, man is the more
1600 Campus Road, Box 829    |   devoted to cheese.  For science has shown that
Los Angeles, CA 90041        |   a mouse will content himself with a piece of
                             |   cheese for want of something better."
   t_pascal@{{{cub,jaguar,cheetah}.math},bobcat,cheshire,tiger}.oxy.edu 

From parc.xerox.com!pavel Fri Nov 13 11:08:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "13" "November" "1992" "10:50:05" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "20" "Re: @players" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29592>; Fri, 13 Nov 1992 11:08:37 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11767>; Fri, 13 Nov 1992 11:06:03 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12109>; Fri, 13 Nov 1992 11:02:08 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Fri, 13 Nov 1992 10:51:05 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12082>; Fri, 13 Nov 1992 10:50:39 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12082>; Fri, 13 Nov 1992 10:50:22 PST
Received: by mu.parc.xerox.com id <58372>; Fri, 13 Nov 1992 10:50:19 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00307C19
In-Reply-to: <9211130426.AA02245@cheshire.oxy.edu>
Message-ID: <92Nov13.105019pst.58372@mu.parc.xerox.com>
References: <9211130426.AA02245@cheshire.oxy.edu>
Date:	Fri, 13 Nov 1992 10:50:05 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	t_pascal@cheshire.oxy.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: @players

> Date:	Thu, 12 Nov 1992 20:26:24 -0800
> From:	t_pascal@cheshire.oxy.edu (C. Regis Wilson)
> 
> >help @players
> 
> Syntax:  @players [with objects]
> 
> Hmmm... what *does* this do, anyway?

With no arguments, this prints out some statistics about the number of players
who have most recently connected within various periods of time.  With the
extra argument, it also prints information about the number of objects each of
those classes of players owns.

One use for this is to see if old, dormant players and their possessions are
consuming a significant fraction of the DB space.  I've also used it to get a
sense of the demographics of LambdaMOO: what percentage of our players visit us
fairly frequently, etc.

	Pavel/Haakon

From xerox.com!staferne.PARC Mon Nov 16 00:29:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "November" "1992" "00:53:58" "-0800" "staferne@terra" "staferne@terra" nil "12" "Bug or Feature ?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 16 Nov 1992 00:28:54 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11529>; Mon, 16 Nov 1992 00:27:18 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11525>; Mon, 16 Nov 1992 00:24:33 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Mon, 16 Nov 1992 00:13:30 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11523>; Mon, 16 Nov 1992 00:11:57 PST
Received: from terra ([140.78.144.2]) by alpha.xerox.com with SMTP id <11528>; Mon, 16 Nov 1992 00:08:18 PST
Received: by terra.risc.uni-linz.ac.at (AIX 3.2/UCB 5.64/4.03)
          id AA13120; Mon, 16 Nov 1992 08:53:58 GMT
X-NS-Transport-ID: 08002008D0FD0030996A
XNS-Originator: staferne.PARC@Xerox.com
Errors-to: staferne.PARC@xerox.com
Message-ID: <9211160853.AA13120@terra.risc.uni-linz.ac.at>
Date:	Mon, 16 Nov 1992 00:53:58 -0800
From:	staferne@terra
Sender: staferne@parc.xerox.com
To:	moo-cows.PARC@xerox.com
Subject: Bug or Feature ?



Yesterday I tried to build a simple object. It should be a bottle and understand
the verb "open". Just as it is, without any arguments. So I created a verb, say
                  add_verb(#15,{player,"rxd","open"},{"none","none","none"})
and then said "open". It did not work. :(
If I changed the arguments of the verb to {"this","none","none"} and said
"open bottle" it worked fine. 
Why didn't that work in the former case?   (I use LambdaMoo-1.6.1)
Is this fixed in LambdaMoo-1.7.0?

Stefan

From xerox.com!parc.xerox.com.PARC Mon Nov 16 07:51:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "November" "1992" "07:39:20" "-0800" "Brian Geiger (GE)" "geiger@suntan.ec.usf.edu" nil "17" "Re: Bug or Feature" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 16 Nov 1992 07:51:01 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11695>; Mon, 16 Nov 1992 07:49:10 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11679>; Mon, 16 Nov 1992 07:47:06 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 16 Nov 1992 07:40:40 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11658>; Mon, 16 Nov 1992 07:40:04 PST
Received: from gort.ec.usf.edu ([131.247.10.61]) by alpha.xerox.com with SMTP id <11658>; Mon, 16 Nov 1992 07:39:23 PST
Received: from suntan.ec.usf.edu by gort.ec.usf.edu with SMTP (5.65/25-eef)
	id AA20781; Mon, 16 Nov 92 10:39:21 -0500
Received:  by suntan.ec.usf.edu (4.1/25-eef)
	id AA23365; Mon, 16 Nov 92 10:39:20 EST
X-NS-Transport-ID: 08002008D0FD00309DA1
XNS-Originator: parc.xerox.com.PARC@Xerox.com
Errors-to: parc.xerox.com.PARC@xerox.com
Message-ID: <9211161539.AA23365@suntan.ec.usf.edu>
Date:	Mon, 16 Nov 1992 07:39:20 -0800
From:	Brian Geiger (GE) <geiger@suntan.ec.usf.edu>
Sender: <@gort.ec.usf.edu:geiger@suntan.ec.usf.EDU>
To:	moo-cows.PARC@xerox.com
Subject: Re: Bug or Feature

'Yesterday I tried to build a simple object. It should be a bottle and understand
the verb "open". Just as it is, without any arguments. So I created a verb, say
                  add_verb(#15,{player,"rxd","open"},{"none","none","none"})
and then said "open". It did not work. :(
If I changed the arguments of the verb to {"this","none","none"} and said
"open bottle" it worked fine. 
Why didn't that work in the former case?   (I use LambdaMoo-1.6.1)
Is this fixed in LambdaMoo-1.7.0?'

The reason that it didn't work is because LambdaMOO will search all of the player's verbs, then all of the room's verbs, then it wil
l stop looking for verbs, without checking the objects that are around.
It does this because 1) the search through the database for all the verbs on all the objects would take up a fair amount of processi
ng power, especially if there are a lot of objects around, and 2) many objects could have the same verb.
So in order to keep it from simply opening the first object it finds, it requires you to specify which object you want to get the ve
rb from.
Besides, you wouldn't go up to someone and say 'open' without giving any idea what you're talking about, would you?
        -Me

From snake.irf.se!larsn Mon Nov 16 08:10:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "November" "1992" "07:39:49" "-0800" "Lars Nilsson" "larsn@snake.irf.se" nil "31" "Re: Bug or feature?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 16 Nov 1992 08:10:17 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11704>; Mon, 16 Nov 1992 08:08:11 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11680>; Mon, 16 Nov 1992 08:06:31 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Mon, 16 Nov 1992 08:03:30 -0800
Received: from snake.irf.se ([192.71.13.7]) by alpha.xerox.com with SMTP id <11689>; Mon, 16 Nov 1992 08:03:05 PST
Received: by snake.irf.se
	(16.8/16.2) id AA03799; Mon, 16 Nov 92 15:39:50 GMT
Mailer: Elm [revision: 70.30]
X-NS-Transport-ID: 08002008D0FD00309E0C
Message-ID: <92Nov16.080305pst.11689@alpha.xerox.com>
Date:	Mon, 16 Nov 1992 07:39:49 -0800
From:	Lars Nilsson <larsn@snake.irf.se>
To:	moo-cows@parc.xerox.com
Subject: Re: Bug or feature?

Hiya, Stefan..

The problem you have with the open verb is perhaps a little strange to
understand at first, but if you read the manual for which objects that
are searched for matching verbs you'll see why this happens.

Objects are searched for verbs in the following order:

	1. The player
	2. The player's location
	3. The direct object
	4. The indirect object

So when you declare the verb to be {"none", "none", "none"} there is no
direct (and no indirect) object, and therefore the verb won't be matched.
The only way to have verbs searched on objects in the player's location
is to have "this" in either the direct or indirect object position.

I hope my explanation is correct. If anyone has anything to add to it,
please do so. I am no expert, so please don't flame me. :)

Lars
--
------------------------------------------------------------------------------
    /      /|   /  Lars Nilsson       | Always listen to experts. They will
   /      / |  /   larsn@snake.irf.se | tell you what can't be done and why.
  /      /  | /    Swedish Institute  | Then do it.
 /____  /   |/     of Space Physics   |                     Robert A. Heinlein
------------------------------------------------------------------------------



From media-lab.media.mit.edu!asb Mon Nov 16 08:16:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "November" "1992" "08:02:38" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "24" "WizardMOO" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 16 Nov 1992 08:16:03 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11698>; Mon, 16 Nov 1992 08:11:54 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11710>; Mon, 16 Nov 1992 08:09:43 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Mon, 16 Nov 1992 08:06:40 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11680>; Mon, 16 Nov 1992 08:04:28 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11680>; Mon, 16 Nov 1992 08:02:40 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA06772; Mon, 16 Nov 92 11:02:39 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD00309DFD
Message-ID: <9211161602.AA06772@media-lab.mit.edu>
Date:	Mon, 16 Nov 1992 08:02:38 -0800
From:	asb@media-lab.media.mit.edu
To:	moo-cows.PARC@xerox.com
Subject: WizardMOO


I'm thinking of opening a MOO where everyone who connects is a 
wizard, but the db is restored once a week.  The idea is to
help people who don't have the hardware or disk space to
bring up their own MOO to learn about the system.

Is this a good idea?

I don't mind if someone crashes the moo or trashes it...  the idea is
that if someone does, no one will be able to use it until the next
automatic restore.  But I do need to make sure that no one finds a way
to crash the machine that it is running on.

What precautions should I take?  

One obvious one is to run it from an account with a quota enforced, so
someone can't just bloat the db to take up our whole drive.
And obviously outbound_network will be disabled!

Someone here has expressed a concern that publicly announcing
it will open our machine to the scrutiny of crackers.  Is this
worth worrying about?

-- Amy

From stony-brook.scrc.symbolics.com!yduJ Mon Nov 16 09:31:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "November" "1992" "09:13:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "29" "WizardMOO" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Mon, 16 Nov 1992 09:31:53 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11740>; Mon, 16 Nov 1992 09:29:40 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11721>; Mon, 16 Nov 1992 09:27:41 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58375>; Mon, 16 Nov 1992 09:24:12 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11713>; Mon, 16 Nov 1992 09:23:34 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11713>; Mon, 16 Nov 1992 09:22:51 PST
Received: from NIMUE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1174500; 16 Nov 1992 12:11:44-0500
X-NS-Transport-ID: 08002008D0FD00309FA4
In-Reply-to: <9211161602.AA06772@media-lab.mit.edu>
Message-ID: <19921116171300.1.YDUJ@NIMUE.SCRC.Symbolics.COM>
Date:	Mon, 16 Nov 1992 09:13:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	asb@media-lab.media.mit.edu, moo-cows.PARC@xerox.com
Subject: WizardMOO

    Date: Mon, 16 Nov 1992 11:02 EST
    From:	asb@media-lab.media.mit.edu

    Someone here has expressed a concern that publicly announcing
    it will open our machine to the scrutiny of crackers.  Is this
    worth worrying about?

If by "public" you mean "moo-cows", I would say there's no real danger.
Indeed, ChaosMOO was up over the summer, an everyone-is-a-wizard moo,
and it really had no problems other than idiots recycling objects by
mistake and toading each other; with your plan there's no problem with
that.  If by "public" you mean "rec.games.mud", then there's the
potential that crackers will try to play.  But with
open_network_connection disabled, there really isn't that much that a
cracker can use the moo for.  If you mean people will say "wow!  There's
a machine named media-lab.media.mit.edu that I could go telnet to!"
because of this announcement, well, I hope nobody from the machine posts
on the net in that case; this is hardly different!

I'd say go for it, even on rec.games.mud.  If it doesn't work out,
change the port number and announce only on moo-cows...

Hmmm.  Actually someone could crash your machine despite the disk quota
by bloating the db; the checkpoint will simply fail, but those objects
will be in memory.  Hopefully instead of crashing the machine when you
run out of swap space, it will crash the MOO program instead.  Anyone
care to offer data points on this?  Presumably this has happened to
LambdaMOO...  Enormous amounts of CPU time could also be used up by the
MOO, which could impact the performance for other users of the machine.

From parc.xerox.com!pavel Mon Nov 16 17:50:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "16" "November" "1992" "17:38:04" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "16" "Re: WizardMOO" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Mon, 16 Nov 1992 17:50:20 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11923>; Mon, 16 Nov 1992 17:48:03 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11915>; Mon, 16 Nov 1992 17:44:11 PST
Received: by mu.parc.xerox.com id <58372>; Mon, 16 Nov 1992 17:38:07 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0030ABA8
In-Reply-to: <19921116171300.1.YDUJ@NIMUE.SCRC.Symbolics.COM>
Message-ID: <92Nov16.173807pst.58372@mu.parc.xerox.com>
References: <19921116171300.1.YDUJ@NIMUE.SCRC.Symbolics.COM>
	<9211161602.AA06772@media-lab.mit.edu>
Date:	Mon, 16 Nov 1992 17:38:04 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Re: WizardMOO

> Date:	Mon, 16 Nov 1992 09:13:00 -0800
> From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>

> Hmmm.  Actually someone could crash your machine despite the disk quota
> by bloating the db; the checkpoint will simply fail, but those objects
> will be in memory.  Hopefully instead of crashing the machine when you
> run out of swap space, it will crash the MOO program instead.  Anyone
> care to offer data points on this?  Presumably this has happened to
> LambdaMOO...  Enormous amounts of CPU time could also be used up by the
> MOO, which could impact the performance for other users of the machine.

When the server uses up a lot of virtual memory, all programs running on that
machine risk having memory allocations fail.  If the server itself fails on
some memory allocation, it panics, halting.

	Pavel/Haakon

From media-lab.media.mit.edu!asb Tue Nov 17 11:56:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "17" "November" "1992" "11:37:13" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "13" "It worked!  Thanks all." "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Tue, 17 Nov 1992 11:56:24 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12259>; Tue, 17 Nov 1992 11:53:45 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12264>; Tue, 17 Nov 1992 11:48:40 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 17 Nov 1992 11:38:37 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12249>; Tue, 17 Nov 1992 11:37:49 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12234>; Tue, 17 Nov 1992 11:37:15 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA08129; Tue, 17 Nov 92 14:37:14 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD0030B9C1
Message-ID: <9211171937.AA08129@media-lab.mit.edu>
Date:	Tue, 17 Nov 1992 11:37:13 -0800
From:	asb@media-lab.media.mit.edu
To:	Moo-cows.parc@xerox.com
Subject: It worked!  Thanks all.


I finally got MOO to compile on our Sun SPARCstation IPC.
Thanks to everyone who sent helpful hints, especially Pavel.

We ended up installing more recent versions of gcc and a lot of other
stuff, and that did the trick.  (Now I even know what YACC and BISON
are!  Quite an education....  :-)

FYI, MOO will not compile with gcc version 1.39.  I'm not sure what
version is required... suggesting at least 2.0 is probably a good
warning to stick somewhere in the documentation.

-- Amy

From nova.decio.nd.edu!jonathan Thu Nov 19 13:48:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Thu" "19" "November" "1992" "13:28:14" "-0800" "Jonathan Bradshaw" "jonathan@nova.decio.nd.edu " "<9211192130.AA04219@nova.decio.nd.edu>" "13" "How goes disk space server?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29584>; Thu, 19 Nov 1992 13:47:55 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11788>; Thu, 19 Nov 1992 13:45:49 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11802>; Thu, 19 Nov 1992 13:41:12 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 19 Nov 1992 13:36:28 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11798>; Thu, 19 Nov 1992 13:35:42 PST
Received: from nova.decio.nd.edu ([129.74.55.91]) by alpha.xerox.com with SMTP id <11801>; Thu, 19 Nov 1992 13:34:53 PST
Received: by nova.decio.nd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA04219; Thu, 19 Nov 92 16:30:35 EST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0030EA05
Message-ID: <9211192130.AA04219@nova.decio.nd.edu>
Date:	Thu, 19 Nov 1992 13:28:14 -0800
From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
To:	moocows@nova.decio.nd.edu
Subject: How goes disk space server?


I was wondering how the disk based server was going? I've had no luck in
tracking down my mysterious "vm_allocate" errors and my only hope now is
for a disk based server or divine intervention, whichever comes first!

Unfortunatly, memory management is not my strong point. 

-- 
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
  Packet: n9oxe@n0ary.#nocal.ca.usa.na | Prodigy: XMSN02B | (Os/2)(DOS)(Linux)
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -


From parc.xerox.com!pavel Fri Nov 20 18:43:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "20" "November" "1992" "18:35:21" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "11" "Re: How goes disk space server?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29587>; Fri, 20 Nov 1992 18:43:43 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12325>; Fri, 20 Nov 1992 18:42:06 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12314>; Fri, 20 Nov 1992 18:39:02 PST
Received: by mu.parc.xerox.com id <58372>; Fri, 20 Nov 1992 18:35:23 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0031037B
In-Reply-to: <9211192130.AA04219@nova.decio.nd.edu>
Message-ID: <92Nov20.183523pst.58372@mu.parc.xerox.com>
References: <9211192130.AA04219@nova.decio.nd.edu>
Date:	Fri, 20 Nov 1992 18:35:21 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	jonathan@nova.decio.nd.edu
cc:	MOO-Cows@parc.xerox.com
Subject: Re: How goes disk space server?

> Date:	Thu, 19 Nov 1992 13:28:14 -0800
> From:	jonathan@nova.decio.nd.edu (Jonathan Bradshaw)
> 
> I was wondering how the disk based server was going?

I am not actively working on the disk-based server (I'm working on some
non-LambdaMOO stuff instead) and I don't have any firm guesses about when I'll
get back to it.  An unreliable guess is that I might release such a server in
January.

	Pavel/Haakon

From wvnvaxa.wvnet.edu!FLORIAN Sat Nov 21 01:13:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "21" "November" "1992" "01:05:14" "-0800" "FLORIAN@wvnvaxa.wvnet.edu" "FLORIAN@wvnvaxa.wvnet.edu" nil "17" "The Player var" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 21 Nov 1992 01:12:53 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12369>; Sat, 21 Nov 1992 01:12:16 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12359>; Sat, 21 Nov 1992 01:09:50 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Sat, 21 Nov 1992 01:06:21 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12324>; Sat, 21 Nov 1992 01:05:56 PST
Received: from WVNVAXA.WVNET.EDU ([129.71.2.1]) by alpha.xerox.com with SMTP id <12324>; Sat, 21 Nov 1992 01:05:13 PST
Received: from WVNVMS.WVNET.EDU by WVNVMS.WVNET.EDU (PMDF #3439 ) id
 <01GREEJ5VVS08WXAET@WVNVMS.WVNET.EDU>; Sat, 21 Nov 1992 04:05:14 EST
X-VMS-To: IN%"Moo-cows@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD0031070F
Message-ID: <01GREEJ5VVS28WXAET@WVNVMS.WVNET.EDU>
Date:	Sat, 21 Nov 1992 01:05:14 -0800
From:	FLORIAN@wvnvaxa.wvnet.edu
To:	Moo-cows.PARC@xerox.com
Subject: The Player var

  Well, I'm attempting to code a generic elevator for my MOO, and I coded
  a verb to list the available destinations.  Unfortunately, I used several
  tell:player() s to display information.  The Verb is coded into the room,
  which is a $room.  Whenever I attempt to execute the verb, I get a 

  Traceback that states that the player variable is not found.  Any idea
  what the problem is?


*******************************************************************************
* Nicholas LaFlamme    *Florian@Wvnvms.Wvnet.edu *  You live and die for      *
* Vagrant, Programmer  *  Cis: [70742,1316]      *   freedom!                 *
* Poet, and Madman     *                         *       -Buzzkirk, Lensman   *
*******************************************************************************
                           But Dr. Pickering, in science as in morality the
                             Ends never justifies the means!.
                                         -The Docter (in Robot)

From cis.ohio-state.edu!weiler Sat Nov 21 08:47:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "21" "November" "1992" "08:40:30" "-0800" "Jerry Weiler" "weiler@cis.ohio-state.edu" nil "7" "Re: The Player var" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 21 Nov 1992 08:47:37 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12527>; Sat, 21 Nov 1992 08:46:41 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12525>; Sat, 21 Nov 1992 08:44:39 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Sat, 21 Nov 1992 08:41:50 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12524>; Sat, 21 Nov 1992 08:41:20 PST
Received: from io.cis.ohio-state.edu ([128.146.25.13]) by alpha.xerox.com with SMTP id <12523>; Sat, 21 Nov 1992 08:40:34 PST
Received: by io.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA05172; Sat, 21 Nov 92 11:40:32 -0500
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD003109D9
In-Reply-to: "<01GREEJ5VVS28WXAET@WVNVMS.WVNET.EDU>; from \"FLORIAN@wvnvaxa.wvnet.edu\" at Nov 21, 92 1:05 am-"
Message-ID: <9211211640.AA05172@io.cis.ohio-state.edu>
Date:	Sat, 21 Nov 1992 08:40:30 -0800
From:	Jerry Weiler <weiler@cis.ohio-state.edu>
To:	moo-cows.PARC@xerox.com
Subject: Re: The Player var

>   Unfortunately, I used several tell:player() s to display information.

this looks for the verb 'player' on the object 'tell'

you want to do it the other way around - player:tell()

- Jerry

From allink.com!paul Mon Nov 23 18:06:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "23" "November" "1992" "17:56:56" "-0800" "paul reiber" "paul@allink.com " nil "28" "Has anyone built 1.7.0 for ..." "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Mon, 23 Nov 1992 18:06:03 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11915>; Mon, 23 Nov 1992 18:05:02 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11923>; Mon, 23 Nov 1992 18:01:59 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 23 Nov 1992 17:59:44 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11805>; Mon, 23 Nov 1992 17:59:20 PST
Received: from uu.psi.com ([136.161.128.3]) by alpha.xerox.com with SMTP id <11926>; Mon, 23 Nov 1992 17:58:36 PST
Received: from pluto.allink.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA17761; Mon, 23 Nov 92 20:57:53 -0500
Received: from rama.nynex.inm by allink.com (4.1/SMI-4.1)
	id AA00809; Mon, 23 Nov 92 20:56:56 EST
X-NS-Transport-ID: 08002008D0FD00312988
Message-ID: <9211240156.AA00809@allink.com>
Date:	Mon, 23 Nov 1992 17:56:56 -0800
From:	paul@allink.com (paul reiber)
To:	Moo-cows.parc@xerox.com
Subject: Has anyone built 1.7.0 for ...

...Um... MS-DOS? Or OS/2?

I'm about to begin using a 386-based notebook,
with more than enough ram and disk to cope with
MOO, and I'm wondering if anyone's already undertaken
the potentially arduous task of building MOO under
DOS or OS/2...

I'm going to have a tough time justifying buying a UNIX
for my notebook on the grounds that MOO wouldn't run
on it otherwise... :)

OR...

(Being new to the '386 arena) Might there be a free,
but DECENT, Unix variant out there that'd run on a
25 Mhz. '386 with 200MB hard disk and 12MB ram? 
And, if so, that someone's brought up MOO1.7 on?

Thanks in advance.

-Paul
 +---------------------+------------------------+-----------------------------+
 | Paul B. Reiber, Jr. | NYNEX Allink Company   | "To Invent, you need a good |
 |  (914)  644 - 7729  | 4 Gannett Drive,       |  Imagination and a Pile of  |
 |   paul@allink.com   | White Plains, NY 10604 |  Junk."     - Thomas Edison |
 +---------------------+------------------------+-----------------------------+


From po.cwru.edu!yjc Mon Nov 23 19:01:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "23" "November" "1992" "18:53:43" "-0800" "Jerome'TofuSoft'Chan" "yjc@po.cwru.edu " nil "7" "Re: Has anyone built 1.7.0 for ..." "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Mon, 23 Nov 1992 19:01:36 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11944>; Mon, 23 Nov 1992 19:01:04 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11940>; Mon, 23 Nov 1992 18:59:05 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 23 Nov 1992 18:56:46 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11939>; Mon, 23 Nov 1992 18:56:23 PST
Received: from nextsun.INS.CWRU.Edu ([129.22.8.51]) by alpha.xerox.com with SMTP id <11940>; Mon, 23 Nov 1992 18:55:49 PST
Received: from b61539.STUDENT.CWRU.Edu by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5-freenet)
	id AA22091; Mon, 23 Nov 92 21:55:44 -0500 (from yjc@po.cwru.edu for Moo-cows.parc@xerox.com)
X-Sender: yjc@pop.cwru.edu
X-NS-Transport-ID: 08002008D0FD00312A40
Message-ID: <9211240255.AA22091@nextsun.INS.CWRU.Edu>
Date:	Mon, 23 Nov 1992 18:53:43 -0800
From:	yjc@po.cwru.edu (Jerome'TofuSoft'Chan)
To:	Moo-cows.parc@xerox.com
Subject: Re: Has anyone built 1.7.0 for ...

>...Um... MS-DOS? Or OS/2?

Ditto but for a Mac II. I've got the Ram and may have the disk space.

---
 The Evil Tofu


From cs.stanford.edu!mrhoten Mon Nov 23 19:08:23 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "23" "November" "1992" "19:02:43" "-0800" "Matthew Rhoten" "mrhoten@cs.stanford.edu" nil "12" "Re:  Has anyone built 1.7.0 for ..." "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Mon, 23 Nov 1992 19:08:21 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11955>; Mon, 23 Nov 1992 19:06:46 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11951>; Mon, 23 Nov 1992 19:05:26 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 23 Nov 1992 19:03:22 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11939>; Mon, 23 Nov 1992 19:03:04 PST
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11939>; Mon, 23 Nov 1992 19:02:42 PST
Received:  by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA08041; Mon, 23 Nov 92 19:02:43 PST
X-NS-Transport-ID: 08002008D0FD00312A54
Message-ID: <9211240302.AA08041@Xenon.Stanford.EDU>
Date:	Mon, 23 Nov 1992 19:02:43 -0800
From:	Matthew Rhoten <mrhoten@cs.stanford.edu>
To:	Moo-cows.parc@xerox.com, paul@allink.com
Subject: Re:  Has anyone built 1.7.0 for ...

There is a free Unix for 386/486 machines, called Linux. I run it on a
325SL notebook with no hitches at all. Linux is available via
anonymous ftp from tsx-11.mit.edu (look in /pub/linux).  Linux is
fast-growing, so is kind of a moving target, but is fairly stable in
my estimation. It's not much of a resource hog - 12M RAM is more than
enough to run MOO on, unless you have a Lambdaish database.

I believe someone (Jonny, perhaps?) compiles LambdaMOO under Linux,
but I don't know if 1.7 is ported yet.

 -matt
  (who plays gnu go in coffeehouses all the time now)

From cis.ohio-state.edu!weiler Mon Nov 23 19:52:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "23" "November" "1992" "19:47:34" "-0800" "Jerry Weiler" "weiler@cis.ohio-state.edu" nil "23" "Re:  Has anyone built 1.7.0 for ..." "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Mon, 23 Nov 1992 19:52:39 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11965>; Mon, 23 Nov 1992 19:52:01 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11967>; Mon, 23 Nov 1992 19:50:40 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 23 Nov 1992 19:48:47 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11961>; Mon, 23 Nov 1992 19:48:20 PST
Received: from io.cis.ohio-state.edu ([128.146.25.13]) by alpha.xerox.com with SMTP id <11964>; Mon, 23 Nov 1992 19:47:44 PST
Received: by io.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA29729; Mon, 23 Nov 92 22:47:37 -0500
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00312AF1
In-Reply-to: "<9211240302.AA08041@Xenon.Stanford.EDU>; from \"Matthew Rhoten\" at Nov 23, 92 7:02 pma/CK7@U>M4"
Message-ID: <9211240347.AA29729@io.cis.ohio-state.edu>
Date:	Mon, 23 Nov 1992 19:47:34 -0800
From:	Jerry Weiler <weiler@cis.ohio-state.edu>
To:	mrhoten@cs.stanford.edu (Matthew Rhoten)
cc:	Moo-cows.parc@xerox.com
Subject: Re:  Has anyone built 1.7.0 for ...

> There is a free Unix for 386/486 machines, called Linux. I run it on a
> 325SL notebook with no hitches at all. Linux is available via
> anonymous ftp from tsx-11.mit.edu (look in /pub/linux).  Linux is
> fast-growing, so is kind of a moving target, but is fairly stable in
> my estimation. It's not much of a resource hog - 12M RAM is more than
> enough to run MOO on, unless you have a Lambdaish database.

I'm using linux 0.94 and (as I've already told Haakon) MOO 1.7.0
compiles almost without a hitch using TCP mode (the config file didn't
select it because I don't have telnet, but it works fine anyway)

the only things I had to change were to comment out the code using
SIGBUS and to take out optimization. gcc 2.2.2 and 2.3.1(alpha) both
blow up trying to optimize execute.c

both tinytalk and mud.el (which are in pub/MOO/clients) work fine

And it's all free!

(As for a Mac II, I have no idea. Linux requires an i386 style computer)

- Jerry
(Lynx on LambdaMOO)

From theory.cs.mankato.msus.edu!nop Mon Nov 23 20:16:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "23" "November" "1992" "20:10:05" "-0800" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "30" "Has anyone built 1.7.0 for ..." "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Mon, 23 Nov 1992 20:16:25 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11976>; Mon, 23 Nov 1992 20:15:26 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11972>; Mon, 23 Nov 1992 20:14:01 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 23 Nov 1992 20:11:47 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11971>; Mon, 23 Nov 1992 20:11:25 PST
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11976>; Mon, 23 Nov 1992 20:10:39 PST
Received: by theory.cs.mankato.msus.edu (5.57/Ultrix3.0-C)
	id AA13809; Mon, 23 Nov 92 22:10:05 -0600
X-NS-Transport-ID: 08002008D0FD00312B34
In-Reply-to: "Matthew Rhoten's message of Mon, 23 Nov 1992 19:02:43 PST <9211240302.AA08041@Xenon.Stanford.EDU>"
Message-ID: <9211240410.AA13809@theory.cs.mankato.msus.edu>
Date:	Mon, 23 Nov 1992 20:10:05 -0800
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	mrhoten@cs.stanford.edu
cc:	Moo-cows.parc@xerox.com, paul@allink.com
Subject: Has anyone built 1.7.0 for ...

> It's not much of a resource hog - 12M RAM is more than
> enough to run MOO on, unless you have a Lambdaish database.

I'll second that.  Linux is one of the highest performance unicies
I've ever used.  One nice win for MOO is that it implements
copy-on-write fork() semantics correctly---when you checkpoint, you
don't immediately double the amount of memory the server takes up.
I'd guess you should be able to run X and emacsen in 12M too,
depending on how big your DB gets.

(Incidentally, I'm planning to run JaysHouseMOO on my home machine,
which is a 8M 486/SX25, over a 19.2k slip line, once it shows up.
Should be interesting.)

> I believe someone (Jonny, perhaps?) compiles LambdaMOO under Linux,
> but I don't know if 1.7 is ported yet.

Me and Comrade independently ported it.  The single user, BSD-style
local networking, and BSD TCP networking all work---I tested the TCP
stuff from my Amiga over SLIP.  Unfortunately, due to an apparent bug
in gcc's back end, add_verb() is broken.  I'm waiting for gcc 2.3.1
before I give up and go in by hand and fix it.

> -matt
>  (who plays gnu go in coffeehouses all the time now)

You make me sick.  :-)

Jay Carlson    Jonny@LambdaMOO
nop@theory.cs.mankato.msus.edu

From netcom.com!dwb Mon Nov 23 20:52:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "23" "November" "1992" "20:38:39" "-0800" "David W. Berry" "dwb@netcom.com " nil "7" "Re: Has anyone built 1.7.0 for the mac" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Mon, 23 Nov 1992 20:52:27 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11981>; Mon, 23 Nov 1992 20:48:16 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11983>; Mon, 23 Nov 1992 20:46:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 23 Nov 1992 20:43:23 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11980>; Mon, 23 Nov 1992 20:42:54 PST
Received: from netcom.netcom.com ([192.100.81.100]) by alpha.xerox.com with SMTP id <11980>; Mon, 23 Nov 1992 20:42:26 PST
Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom)
	id AA11429; Mon, 23 Nov 92 20:38:39 -0800
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00312B82
In-Reply-to: "<9211240255.AA22091@nextsun.INS.CWRU.Edu>; from \"Jerome'TofuSoft'Chan\" at Nov 23, 92 6:53 pmhe of Stab"
Message-ID: <9211240438.AA11429@netcom.netcom.com>
Date:	Mon, 23 Nov 1992 20:38:39 -0800
From:	dwb@netcom.com (David W. Berry)
To:	yjc@po.cwru.edu (Jerome'TofuSoft'Chan)
cc:	Moo-cows.parc@xerox.com
Subject: Re: Has anyone built 1.7.0 for the mac

> Ditto but for a Mac II. I've got the Ram and may have the disk space.
> 
I built and ran 1.5 or 1.6 on a mac running A/UX.  gcc 2.2.2 compiled
it and it ran just fine.  Haven't actually found the time to try 1.7
yet, but I wouldn't expect any problems.



From xerox.com!PARC.xerox.com.PARC Tue Nov 24 10:04:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "09:56:35" "-0800" "\"Jon Brazelton, Residence Hall Coordinator\"" "JPB7946%TNTECH.bitnet@cunyvm.cuny.edu" nil "26" "Finding Linux" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Tue, 24 Nov 1992 10:04:28 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12206>; Tue, 24 Nov 1992 10:03:28 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12210>; Tue, 24 Nov 1992 10:00:02 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 24 Nov 1992 09:58:08 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12201>; Tue, 24 Nov 1992 09:57:43 PST
Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <12219>; Tue, 24 Nov 1992 09:56:48 PST
Received: from TNTECH.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2)
   with BSMTP id 3889; Tue, 24 Nov 92 12:56:13 EST
Received: from TNTECH.BITNET by TNTECH.BITNET (PMDF #2902 ) id
 <01GRJ1Q16FCWCMHY72@TNTECH.BITNET>; Tue, 24 Nov 1992 11:56:35 CST
X-Envelope-to: moo-cows.parc@xerox.com
X-VMS-To: IN%"moo-cows.parc@xerox.com"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
X-NS-Transport-ID: 08002008D0FD0031356D
XNS-Originator: PARC.xerox.com.PARC@Xerox.com
Errors-to: PARC.xerox.com.PARC@xerox.com
Message-ID: <01GRJ1Q16P02CMHY72@TNTECH.BITNET>
Date:	Tue, 24 Nov 1992 09:56:35 -0800
From:	"Jon Brazelton, Residence Hall Coordinator" <JPB7946%TNTECH.bitnet@cunyvm.cuny.edu>
Sender: <@cunyvm.cuny.edu:JPB7946@TNTECH.BITNET>
To:	moo-cows.parc@xerox.com
Subject: Finding Linux

I have a couple of questions concerning the recent posts:

        1.      Where can I find a recent copy of Linux?  I did an Archie
                search, and it provided over 1500 references to Linux.  I
                need an FTP address and directory.

        2.      What use is there for LambdaMOO on a PC-based system?  Is
                this something that would run on a BBS, or what?  I am
                having trouble visualizing multi-user input on a
                non-mainframe or non-network system.

        3.      If there IS a use for LambdaMOO on a PC (which obviously
                there must be, with all the interest shown here), where
                can the most recent version be found?  I assume XEROX.COM
                would be a good place to start ... just wondering if there
                are any other sources.

Thanks for the assistance here, and see you in the MOO.

---------------------------------------------------------------------------
                           Jon Brazelton / N4VRN
Residence Hall Coordinator               First Lieutenant (P), Signal Corps
Tennessee Technological University       278th Armored Cavalry Regiment
Cookeville, Tennessee                    Tennessee Army National Guard
                          JPB7946 @ TNTECH.edu
---------------------------------------------------------------------------

From offserv2.faa.gov!warb Tue Nov 24 10:40:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "10:31:28" "-0800" "warb@tgf.tc.faa.gov" "warb@tgf.tc.faa.gov" nil "21" "Re: Finding Linux" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Tue, 24 Nov 1992 10:40:46 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12220>; Tue, 24 Nov 1992 10:40:11 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12201>; Tue, 24 Nov 1992 10:35:08 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 24 Nov 1992 10:33:23 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12214>; Tue, 24 Nov 1992 10:33:00 PST
Received: from faatcrl.Faa.Gov ([155.178.252.2]) by alpha.xerox.com with SMTP id <12221>; Tue, 24 Nov 1992 10:32:07 PST
Received: from offserv2.tgf.tc.faa.gov by faatcrl.Faa.Gov with SMTP id AA17318
  (5.65b/IDA-1.4.3 for MOO-Cows@Xerox.com); Tue, 24 Nov 92 13:39:48 -0500
Received: from mars.tgf.faa.gov by tgf.tc.faa.gov (4.1/SMI-4.1)
	id AA08354; Tue, 24 Nov 92 13:31:28 EST
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD0031364F
In-Reply-to: "<01GRJ1Q16P02CMHY72@TNTECH.BITNET>; from \"Jon Brazelton, Residence Hall Coordinator\" at Nov 24, 92 9:56 amkam@J4AT7%,@"
Message-ID: <9211241831.AA08354@tgf.tc.faa.gov>
Date:	Tue, 24 Nov 1992 10:31:28 -0800
From:	warb@tgf.tc.faa.gov
Sender: warb@offserv2.faa.gov
To:	JPB7946@TNTECH.bitnet (Jon Brazelton Residence Hall Coordinator)
cc:	MOO-Cows@xerox.com (Lambda MOO Programmers)
Subject: Re: Finding Linux
Reply-to: warb@tgf.tc.faa.gov

> 
> I have a couple of questions concerning the recent posts:
> 
>         1.      Where can I find a recent copy of Linux?  I did an Archie

                  ftp tsx-11.mit.edu
> 
>         2.      What use is there for LambdaMOO on a PC-based system?  Is

		  I don't know, but I imagin(sp) that you could build objects
		  and test them then transfer them to an active moo.
> 
>         3.      If there IS a use for LambdaMOO on a PC (which obviously

                  Sorry, cannot help with this one.
-- 
Dan Warburton warb@faa.gov warb@tgf.tc.faa.gov warb@pilot.njin.net 
TGF (Target Generation Facility, an Air Traffic Control Simulator) 
FAA Technical Center, Atlantic City International Airport, NJ
08405  Mail Stop ACN-400c  Phone: 609-484-4480 


From xerox.com!parc.xerox.com.PARC Tue Nov 24 10:45:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "10:31:26" "-0800" "Dave Siegel" "dsiegel@seagull.sky.tucson.az.us " nil "47" "Re: Finding Linux" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Tue, 24 Nov 1992 10:45:47 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12235>; Tue, 24 Nov 1992 10:44:17 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12219>; Tue, 24 Nov 1992 10:41:08 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 24 Nov 1992 10:38:00 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12231>; Tue, 24 Nov 1992 10:37:27 PST
Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <12229>; Tue, 24 Nov 1992 10:36:34 PST
Received: from TNTECH.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2)
   with BSMTP id 4630; Tue, 24 Nov 92 13:34:59 EST
Received: from CUNYVM.BITNET (MAILER@CUNYVMV2) by TNTECH.BITNET (PMDF #2902 )
 id <01GRJ3BO6180CHJ23M@TNTECH.BITNET>; Tue, 24 Nov 1992 12:35:24 CST
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 1373; Tue,
 24 Nov 92 13:33:52 EST
Received: from Arizona.edu by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Tue,
 24 Nov 92 13:33:48 EST
Received: from seagull.sky.tucson.az.us by Arizona.edu (PMDF #2381 ) id
 <01GRJ16N29IO9ODBUC@Arizona.edu>; Tue, 24 Nov 1992 11:34:09 MST
Received: by seagull.sky.tucson.az.us (4.1/SMI-4.1) id AA00962; Tue,
 24 Nov 92 11:31:28 MST
X-Envelope-to: moo-cows.parc@xerox.com
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD00313667
XNS-Originator: parc.xerox.com.PARC@Xerox.com
Errors-to: parc.xerox.com.PARC@xerox.com
In-Reply-to: "<01GRJ1Q16P02CMHY72@TNTECH.BITNET>; from
 \"Jon Brazelton, Residence Hall Coordinator\" at Nov 24, 92 9:56 am"
Message-ID: <9211241831.AA00962@seagull.sky.tucson.az.us>
Date:	Tue, 24 Nov 1992 10:31:26 -0800
From:	dsiegel@seagull.sky.tucson.az.us (Dave Siegel)
Sender: <@cunyvm.cuny.edu:dsiegel@seagull.sky.tucson.az.US>
To:	JPB7946%TNTECH.bitnet@cunyvm.cuny.edu (Jon Brazelton, Residence Hall Coordinator)
cc:	moo-cows.parc%xerox.com%TNTECH.bitnet@cunyvm.cuny.edu (Jon Brazelton Residence Hall Coordinator)
Subject: Re: Finding Linux

>
> I have a couple of questions concerning the recent posts:
>
>         1.      Where can I find a recent copy of Linux?  I did an Archie
>                 search, and it provided over 1500 references to Linux.  I
>                 need an FTP address and directory.
>
tsx-11.mit.edu  don't remember the directory, but it didn't take too long to
find it last time.
>         2.      What use is there for LambdaMOO on a PC-based system?  Is
>                 this something that would run on a BBS, or what?  I am
>                 having trouble visualizing multi-user input on a
>                 non-mainframe or non-network system.
>
obviously, your assesment of the PC architecture is flawed.  By placing unix
on your PC, you can turn it into what you might consider a networking
mainframe system.  Linux is one free way of doing that.  I paid $1600
for a variant of AT&T's System V, Release 4 produced by Dell, Inc.  It
runs on my 486, and beats the snot out of a SPARC.

>         3.      If there IS a use for LambdaMOO on a PC (which obviously
>                 there must be, with all the interest shown here), where
>                 can the most recent version be found?  I assume XEROX.COM
>                 would be a good place to start ... just wondering if there
>                 are any other sources.
>

see above.  It has the same funtionality as any other MOO running on any other
variant of Unix.

> Thanks for the assistance here, and see you in the MOO.
>
> ---------------------------------------------------------------------------
>                            Jon Brazelton / N4VRN
> Residence Hall Coordinator               First Lieutenant (P), Signal Corps
> Tennessee Technological University       278th Armored Cavalry Regiment
> Cookeville, Tennessee                    Tennessee Army National Guard
>                           JPB7946 @ TNTECH.edu
> ---------------------------------------------------------------------------
>
-dave
"capt_seagull"

--
Dave Siegel
System Manager, Seagull.Sky.Tucson.AZ.US
dsiegel@seagull.sky.tucson.az.us, root@seagull.sky.tucson.az.us

From cobra.jpl.nasa.gov!urban Tue Nov 24 13:37:25 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "13:25:57" "-0800" "Michael P Urban" "urban@cobra.jpl.nasa.gov" "<92Nov24.132559pst.12282@alpha.xerox.com>" "5" "8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29586>; Tue, 24 Nov 1992 13:37:16 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12288>; Tue, 24 Nov 1992 13:35:17 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12282>; Tue, 24 Nov 1992 13:32:21 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Tue, 24 Nov 1992 13:28:27 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12275>; Tue, 24 Nov 1992 13:26:50 PST
Received: from sideshow.jpl.nasa.gov ([128.149.70.41]) by alpha.xerox.com with SMTP id <12282>; Tue, 24 Nov 1992 13:25:59 PST
Received: by sideshow.jpl.nasa.gov
	(16.8/16.2) id AA17291; Tue, 24 Nov 92 13:25:58 -0800
X-Face: %q"[Odr2u&o(@]W>9%kwwJ/Td+Ju5!en}ZHQ>G3)9%`RBr7Ct12Dj6LB\Qz@@j|YgfHymB~
 Lc>qe:o+U{rh!RVuaYYd{+S4$8tPLu]Y$0<5x>rj-kuS"[eqLFME-('jwXR87s;A3I,=cW*D(><s+w
 Yi%=%}H?|1mR`pc0qrR!<y:
X-NS-Transport-ID: 08002008D0FD00313A42
Message-ID: <92Nov24.132559pst.12282@alpha.xerox.com>
Date:	Tue, 24 Nov 1992 13:25:57 -0800
From:	Michael P Urban <urban@cobra.jpl.nasa.gov>
To:	moo-cows.parc@xerox.com
Subject: 8-bit MOO?

I observe that MOO appears to accept only ASCII characters.  What
changes would be required for it to accept 8-bit characters, so that
someone could implement a French MOO or whatever using the ISO 8859
character set?


From parc.xerox.com!pavel Tue Nov 24 15:17:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "15:06:17" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "27" "Re: 8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29586>; Tue, 24 Nov 1992 15:17:24 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12332>; Tue, 24 Nov 1992 15:14:33 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12321>; Tue, 24 Nov 1992 15:11:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58378>; Tue, 24 Nov 1992 15:07:55 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12346>; Tue, 24 Nov 1992 15:06:49 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12335>; Tue, 24 Nov 1992 15:06:28 PST
Received: by mu.parc.xerox.com id <58378>; Tue, 24 Nov 1992 15:06:24 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00313C7D
In-Reply-to: <92Nov24.132559pst.12282@alpha.xerox.com>
Message-ID: <92Nov24.150624pst.58378@mu.parc.xerox.com>
References: <92Nov24.132559pst.12282@alpha.xerox.com>
Date:	Tue, 24 Nov 1992 15:06:17 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	urban@cobra.jpl.nasa.gov
cc:	moo-cows.parc@xerox.com
Subject: Re: 8-bit MOO?

> Date:	Tue, 24 Nov 1992 13:25:57 -0800
> From:	Michael P Urban <urban@cobra.jpl.nasa.gov>
> 
> I observe that MOO appears to accept only ASCII characters.  What
> changes would be required for it to accept 8-bit characters, so that
> someone could implement a French MOO or whatever using the ISO 8859
> character set?

The server checks, on input from the network, that the characters satisfy the
`isgraph()' macro in <ctype.h>.  This test is (unfortunately duplicated) in
net_single.c and net_multi.c.

The parser/compiler and unparser for the MOO language also make some checks
that would have to be made right for a Latin-1 environment; these have to do
with the syntax of MOO identifiers.

It may be that you'd only need to do some simple little trick with ANSI C
`locales', but I've avoided knowing anything about those, so I couldn't give
you any more details.

In any case, there is nothing in the server code that assumes that the high bit
of a character is always zero or any other such nonsense, so it would be
straightforward to make it work with any 8-bit encoding.  Making it work with
multibyte characters would probably be less straightforward, but still not
particularly tough.

	Pavel

From unipress.com!joe Tue Nov 24 15:52:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "15:44:05" "-0800" "joe@unipress.com" "joe@unipress.com" "<9211242344.AA03700@repo.unipress.com>" "10" "Re: 8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29586>; Tue, 24 Nov 1992 15:52:12 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12347>; Tue, 24 Nov 1992 15:51:17 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12352>; Tue, 24 Nov 1992 15:49:14 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58379>; Tue, 24 Nov 1992 15:45:10 -0800
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <12346>; Tue, 24 Nov 1992 15:44:43 PST
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA25753; Tue, 24 Nov 92 18:44:34 EST
Received: from dot.UniPress.COM by repo.unipress.com (4.1/SMI-4.1/UniPress080492.1)
	id AA03700; Tue, 24 Nov 92 18:44:29 EST via
X-NS-Transport-ID: 08002008D0FD00313D4B
Message-ID: <9211242344.AA03700@repo.unipress.com>
Date:	Tue, 24 Nov 1992 15:44:05 -0800
From:	joe@unipress.com
To:	moo-cows@parc.xerox.com
Subject: Re: 8-bit MOO?


I haven't looked, but I can tell you that the first thing that I would suspect
when moving to 8 bit chars would be regular expression code.  Often, the NDFA
encoding used by regexp packages makes use of the high bit in search text.

--joe
SRI SYADASTI SYADAVAKTAVYA SYADASTI SYANNASTI SYADASTI CAVAKTAVYASCA
SYADASTI SYANNASTI SYADAVATAVYASCA SYADASTI SYANNASTI SYADAVAKTAVYASCA

WARNING: class has only private members and no friends.

From parc.xerox.com!pavel Tue Nov 24 16:55:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "16:48:33" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "15" "New release of LambdaCore.db" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29586>; Tue, 24 Nov 1992 16:54:54 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12374>; Tue, 24 Nov 1992 16:54:31 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12382>; Tue, 24 Nov 1992 16:51:55 PST
Received: by mu.parc.xerox.com id <58380>; Tue, 24 Nov 1992 16:48:38 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00313EC1
Message-ID: <92Nov24.164838pst.58380@mu.parc.xerox.com>
Date:	Tue, 24 Nov 1992 16:48:33 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: New release of LambdaCore.db

I have extracted a new version of the LambdaCore database; it is available for
anonymous FTP from `parcftp.xerox.com' in the directory `pub/MOO' as the files

		LambdaCore-24Nov92.db
or
		LambdaCore-24Nov92.db.Z

If you fetch the compressed version (.Z), be sure to use `binary' mode.

You'll notice that this version is somewhat larger than the previous one; the
principal reason is that the core now includes the English spelling dictionary
that was downloaded onto LambdaMOO some time ago by waffle.  You can get rid of
the extra space, if you desire, by simply recycling `$spell'.

	Pavel/Haakon

From parc.xerox.com!pavel Tue Nov 24 17:02:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "16:52:26" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "13" "Re: 8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29586>; Tue, 24 Nov 1992 17:01:57 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12380>; Tue, 24 Nov 1992 17:00:35 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12370>; Tue, 24 Nov 1992 16:58:25 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58381>; Tue, 24 Nov 1992 16:55:00 -0800
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12387>; Tue, 24 Nov 1992 16:52:32 PST
Received: by mu.parc.xerox.com id <58381>; Tue, 24 Nov 1992 16:52:28 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00313ED9
In-Reply-to: <9211242344.AA03700@repo.unipress.com>
Message-ID: <92Nov24.165228pst.58381@mu.parc.xerox.com>
References: <9211242344.AA03700@repo.unipress.com>
Date:	Tue, 24 Nov 1992 16:52:26 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	joe@unipress.com
cc:	moo-cows@parc.xerox.com
Subject: Re: 8-bit MOO?

> Date:	Tue, 24 Nov 1992 15:44:05 -0800
> From:	joe@unipress.com
> 
> I haven't looked, but I can tell you that the first thing that I would
> suspect when moving to 8 bit chars would be regular expression code.  Often,
> the NDFA encoding used by regexp packages makes use of the high bit in search
> text.

Joe makes a good point here; I forgot to check the regexp library code.  It
would also need to be checked to make sure that it had the correct notion of
what a `word-constituent' character was.

	Pavel

From cs.stanford.edu!crew Tue Nov 24 21:11:29 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "21:01:54" "-0800" "Roger Crew" "crew@cs.stanford.edu" nil "7" "Re: 8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <71811>; Tue, 24 Nov 1992 21:11:28 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12450>; Tue, 24 Nov 1992 21:10:00 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12446>; Tue, 24 Nov 1992 21:06:27 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58382>; Tue, 24 Nov 1992 21:02:30 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12440>; Tue, 24 Nov 1992 21:02:18 PST
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <12443>; Tue, 24 Nov 1992 21:01:51 PST
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA22489; Tue, 24 Nov 92 21:01:55 PST
X-NS-Transport-ID: 08002008D0FD00314238
In-Reply-to: "\"Your message of \\\"Tue, 24 Nov 92 15:06:17 PST.\\\"
             <92Nov24.150624pst.58378@mu.parc.xerox.com>m.comlobe"
Message-ID: <92Nov24.210218pst.12440@alpha.xerox.com>
Date:	Tue, 24 Nov 1992 21:01:54 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: 8-bit MOO?

	"
To: moo-cows.PARC@Xerox.com
Message-ID: <9211250501.AA22489@Xenon.Stanford.EDU>

Don't the case-insensitive string comparison and search functions
(index,strsub, etc...) make assumptions about the way the character
set is laid out?

From unipress.com!joe Tue Nov 24 21:54:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "24" "November" "1992" "21:46:23" "-0800" "joe@unipress.com" "joe@unipress.com" nil "26" "Re: 8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <71811>; Tue, 24 Nov 1992 21:54:16 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12458>; Tue, 24 Nov 1992 21:53:31 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12459>; Tue, 24 Nov 1992 21:51:56 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58383>; Tue, 24 Nov 1992 21:47:32 -0800
Received: from remus.rutgers.edu ([128.6.13.3]) by alpha.xerox.com with SMTP id <12456>; Tue, 24 Nov 1992 21:47:06 PST
Received: from unipress-link.rutgers.edu by remus.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) 
	id AA14053; Wed, 25 Nov 92 00:46:53 EST
Received: from dot.UniPress.COM by repo.unipress.com (4.1/SMI-4.1/UniPress080492.1)
	id AA04390; Wed, 25 Nov 92 00:46:44 EST via
X-NS-Transport-ID: 08002008D0FD003142C2
In-Reply-to: "Your message of \"Tue, 24 Nov 92 21:01:54 PST.\"
             <92Nov24.210218pst.12440@alpha.xerox.com> "
Message-ID: <9211250546.AA04390@repo.unipress.com>
Date:	Tue, 24 Nov 1992 21:46:23 -0800
From:	joe@unipress.com
To:	Roger Crew <crew@cs.stanford.edu>
cc:	moo-cows@parc.xerox.com
Subject: Re: 8-bit MOO?


> Don't the case-insensitive string comparison and search functions
> (index,strsub, etc...) make assumptions about the way the character set is
> laid out?

I could be lying, but I believe that the functions toupper(), tolower(), etc.
from the ANSI, POSIX, ISO, FIPS, etc.  need to be relinked to an
internationalized libc's versions of these functions.

A good implementation of these functions and macros will use a 256 wide array
of 8 wide bit strings, each flag in each of the bit strings flagging inclusion
in a set, like numerics or capitals.  To change language locales then, all you
have to do is point the macros and functions at the new language's array.

I don't think this is really a problem.  The main concern is user code which
assumes that the 8th bit in a char is unused.  If you do that, and your
platform claims to do other languages, then you're as 8 bit clean as you can
get, theoretically.

--joe
SRI SYADASTI SYADAVAKTAVYA SYADASTI SYANNASTI SYADASTI CAVAKTAVYASCA
SYADASTI SYANNASTI SYADAVATAVYASCA SYADASTI SYANNASTI SYADAVAKTAVYASCA

WARNING: class has only private members and no friends.



From cobra.jpl.nasa.gov!urban Wed Nov 25 07:44:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "25" "November" "1992" "07:36:55" "-0800" "Michael P Urban" "urban@cobra.jpl.nasa.gov" nil "41" "Re: 8-bit MOO?" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <71811>; Wed, 25 Nov 1992 07:44:02 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12626>; Wed, 25 Nov 1992 07:42:36 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12627>; Wed, 25 Nov 1992 07:39:06 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Wed, 25 Nov 1992 07:37:15 -0800
Received: from sideshow.jpl.nasa.gov ([128.149.70.41]) by alpha.xerox.com with SMTP id <12619>; Wed, 25 Nov 1992 07:36:58 PST
Received: by sideshow.jpl.nasa.gov
	(16.8/16.2) id AA25340; Wed, 25 Nov 92 07:36:56 -0800
X-Face: %q"[Odr2u&o(@]W>9%kwwJ/Td+Ju5!en}ZHQ>G3)9%`RBr7Ct12Dj6LB\Qz@@j|YgfHymB~
 Lc>qe:o+U{rh!RVuaYYd{+S4$8tPLu]Y$0<5x>rj-kuS"[eqLFME-('jwXR87s;A3I,=cW*D(><s+w
 Yi%=%}H?|1mR`pc0qrR!<y:
X-NS-Transport-ID: 08002008D0FD00314893
In-Reply-to: "Your message of \"Tue, 24 Nov 92 21:46:23 PST.\"
             <9211250546.AA04390@repo.unipress.com>that"
Message-ID: <92Nov25.073658pst.12619@alpha.xerox.com>
Date:	Wed, 25 Nov 1992 07:36:55 -0800
From:	Michael P Urban <urban@cobra.jpl.nasa.gov>
To:	moo-cows@parc.xerox.com
Subject: Re: 8-bit MOO?

Your message dated: Tue, 24 Nov 92 21:46:23 PST
> 
> > Don't the case-insensitive string comparison and search functions
> > (index,strsub, etc...) make assumptions about the way the character set is
> > laid out?
> 
> I could be lying, but I believe that the functions toupper(), tolower(), etc.
> from the ANSI, POSIX, ISO, FIPS, etc.  need to be relinked to an
> internationalized libc's versions of these functions.

Well, this was an educational experience for me (so I can vaguely
justify the time I spent on it...:-) )

On HP/UX (the system I am using), functions like `toupper', the regexp
functions, the ctype functions, string collation functions, and time
conversion functions can be affected by the Native Language Support
(NLS) environment.  Adding a call to the library routine `setlocale'
will make subsequent calls to these routines behave appropriately for
the local language.  This is fairly flexible; you can set `LC_CTYPE'
behavior without setting `LC_TIME' behavior, so that `isupper' et al.
do the right things for French without causing the output from ctime
to be in French, for example.  Adding the setlocale call did not work
initially, incidentally; the calls to `isgraph' in net_multi.c and
net_single.c also had to be changed to explicitly cast their arguments
to the (correct) type int, rather than char; C programmers take note.
After that change, invoking moo with something like (setenv LANG
french; moo ...) allowed me to enter funny French characters to my
coeur's content.

For lovers of standards, The HP/UX manual page for `setlocale' has the
following information:

 STANDARDS CONFORMANCE
      setlocale: XPG3, POSIX.1, FIPS 151-1, ANSI C

I believe that more recent SunOS, uh, Solaris releases also provide
this facility, although particular installations will not have language
support for particular locales (I was sort of amazed that our rather
vanilla HP/UX system included locales like czech).

	Mike

From xerox.com!PARC.xerox.com.PARC Tue Dec  1 17:26:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "1" "December" "1992" "17:09:52" "-0800" "Winthrop D Chan" "wdc50@cd.amdahl.com " nil "6" "Updated LambdaCoreUser/Prog manuals?" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43020>; Tue, 1 Dec 1992 17:26:39 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11894>; Tue, 1 Dec 1992 17:22:49 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11851>; Tue, 1 Dec 1992 17:15:47 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 1 Dec 1992 17:11:29 -0800
Received: from amdahl.com ([129.212.11.3]) by alpha.xerox.com with SMTP id <11844>; Tue, 1 Dec 1992 17:11:06 PST
Received: by amdahl.com (/\==/\ Smail #25.32)
	id <m0mwicD-0000DJC@amdahl.com>; Tue, 1 Dec 92 17:10 PST
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.12)
	id <m0mwicB-00007OC@amdahl.uts.amdahl.com>; Tue, 1 Dec 92 17:10 PST
Received: by juts.ccc.amdahl.com (/\../\ Smail3.1.14.4 #14.6)
	id <m0mwicR-0000eKC@juts.ccc.amdahl.com>; Tue, 1 Dec 92 17:11 PST
Received: from blackflag.CD by manager.cd.amdahl.com (4.1/SMI-4.1)
	id AA27886; Tue, 1 Dec 92 17:09:52 PST
X-NS-Transport-ID: 08002008D0FD00319A22
Message-ID: <9212020109.AA27886@manager.cd.amdahl.com>
Date:	Tue, 1 Dec 1992 17:09:52 -0800
From:	wdc50@cd.amdahl.com (Winthrop D Chan)
Sender: PARC.xerox.com.PARC@xerox.com
To:	MOO-Cows@parc.xerox.com
Subject: Updated LambdaCoreUser/Prog manuals?

Is there going to be any attempt in the future to update the LambdaCore
Programmers and Users Manuals? Surely the core has been updated several times
since then to justify some additions to the manual.

Thanks!
Winthrop /Pax/ Chan

From stony-brook.scrc.symbolics.com!yduJ Tue Dec  1 18:53:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "1" "December" "1992" "18:42:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "11" "Updated LambdaCoreUser/Prog manuals?" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43020>; Tue, 1 Dec 1992 18:53:40 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11861>; Tue, 1 Dec 1992 18:52:28 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11860>; Tue, 1 Dec 1992 18:48:06 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 1 Dec 1992 18:41:56 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11869>; Tue, 1 Dec 1992 18:40:58 PST
Received: from MR-WIZARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1181503; 1 Dec 1992 21:41:58-0500
X-NS-Transport-ID: 08002008D0FD00319BDC
In-Reply-to: <9212020109.AA27886@manager.cd.amdahl.com>
Message-ID: <19921202024200.5.YDUJ@MR-WIZARD.SCRC.Symbolics.COM>
Date:	Tue, 1 Dec 1992 18:42:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	wdc50@cd.amdahl.com, MOO-Cows@parc.xerox.com
Subject: Updated LambdaCoreUser/Prog manuals?

    Date: Tue, 1 Dec 1992 20:09 EST
    From:	wdc50@cd.amdahl.com (Winthrop D Chan)

    Is there going to be any attempt in the future to update the LambdaCore
    Programmers and Users Manuals? Surely the core has been updated several times
    since then to justify some additions to the manual.

The LambdaCore programmer and user manuals were contributed by a
volunteer.  I don't know if these folks are still interested in
MOOing...  It would be delightful if someone would take it upon
themselves to update the manuals...

From hplb.hpl.hp.com!mjp Wed Dec  2 02:21:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "2" "December" "1992" "01:59:10" "-0800" "Mike Prudence" "mjp@hplb.hpl.hp.com" nil "33" "Re: Updated LambdaCoreUser/Prog manuals" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43020>; Wed, 2 Dec 1992 02:21:46 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11805>; Wed, 2 Dec 1992 02:20:52 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11879>; Wed, 2 Dec 1992 02:15:14 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Wed, 2 Dec 1992 02:03:21 -0800
Received: from hplb.hpl.hp.com ([15.255.59.2]) by alpha.xerox.com with SMTP id <11805>; Wed, 2 Dec 1992 02:03:03 PST
Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Wed, 2 Dec 92 10:01:06 GMT
Received: by prudence.hpl.hp.com with SMTP
	(15.11/15.6+ISC) id AA13578; Wed, 2 Dec 92 09:59:11 gmt
X-NS-Transport-ID: 08002008D0FD00319FB8
Message-ID: <9212020959.AA13578@prudence.hpl.hp.com>
Date:	Wed, 2 Dec 1992 01:59:10 -0800
From:	Mike Prudence <mjp@hplb.hpl.hp.com>
To:	MOO-cows@parc.xerox.com
Subject: Re: Updated LambdaCoreUser/Prog manuals

Hi all,

Recently  wdc50@cd.amdahl.com (Winthrop D Chan) said:

> Is there going to be any attempt in the future to update the LambdaCore
> Programmers and Users Manuals? Surely the core has been updated several times
> since then to justify some additions to the manual.

Well, I'm the guy who sort of coordinated effort on this one.  It
hasn't been updated for several reasons.  It was mainly written to
help fledgling programmers on our HP-internal MOO to get up to speed,
this ot describes the LambdaCore on which our MOO is based.  As there
is no good upgrade path for adding in new Core versions, this document
would start to diverge wildly from what is actually in the LambdaCore,
as we would have to pick and choose things to port over, depending on
time/resources/usefulness.  For example, the notion of a spell checker
in a MOO makes my stomach turn, and so we haven't ported it to our
MOO.

What you really need is someone who lives in Lambda to take this up
and bring it in to line with the core there.  Then us folks could just
snaffle the bits we need to make our internal documentation up to
date.

Any takers ??

Cheers,

Mike

mjp@hplb.hpl.hp.com                   "Only those who attempt the absurd will 
                                                     achieve the impossible."


From athena.mit.edu!ghudson Thu Dec  3 07:02:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Thu" "3" "December" "1992" "06:41:16" "-0800" "Greg Hudson" "ghudson@athena.mit.edu" "<9212031441.AA23387@torque-wrench>" "29" "OUTPUT*FIX" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43022>; Thu, 3 Dec 1992 07:02:14 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11594>; Thu, 3 Dec 1992 07:00:16 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11589>; Thu, 3 Dec 1992 06:56:15 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 3 Dec 1992 06:42:17 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11544>; Thu, 3 Dec 1992 06:42:02 PST
Received: from Athena.MIT.EDU ([18.72.1.1]) by alpha.xerox.com with SMTP id <11544>; Thu, 3 Dec 1992 06:41:27 PST
Received: from TORQUE-WRENCH.MIT.EDU by Athena.MIT.EDU with SMTP
	id AA03990; Thu, 3 Dec 92 09:41:24 EST
Received: by torque-wrench (5.57/4.7) id AA23387; Thu, 3 Dec 92 09:41:17 -0500
X-NS-Transport-ID: 08002008D0FD0031BA4E
Message-ID: <9212031441.AA23387@torque-wrench>
Date:	Thu, 3 Dec 1992 06:41:16 -0800
From:	Greg Hudson <ghudson@athena.mit.edu>
To:	MOO-Cows.PARC@xerox.com
Subject: OUTPUT*FIX


A couple of commands I've noticed conspicuously missing in MOO are
OUTPUTPREFIX and OUTPUTSUFFIX.  A look at the programmer's reference
indicates that they would probably have to be treated in the server
code, which is a bit unfortunate aesthetically, but they are crucial
tools for intelligent clients.

Right now, VT has a number of tools which require the ability to get
the output of a command, a simple task on every social-mud server
except for MOO.  For instance, someone recently asked me what output I
get if I tried to take one of his objects.  Had I bracketing ability
on MOO, I could have simple typed "take Bob^XQ" or entered "/cquote
take Bob" and had sent to the MOO automatically:
	:> take Bob
	:| Sorry.
	:| You cannot pick that up.

Likewise, if I want to know what flags are set on me, I could do
"/filter Flags: * = @show me", similar to how I use /filter on other
kinds of servers.

I've heard tell that OUTPUT*FIX were taken out of the server at some
point, perhaps during the period when robots became unpopular.  I
don't think that's a consideration any more, and as clients get more
sophisticated, it's clear that at least some primitive way of dealing
with typed data streams is in order.

Any thoughts on this?


From parc.xerox.com!pavel Thu Dec  3 10:48:57 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "3" "December" "1992" "10:18:13" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "86" "Re: OUTPUT*FIX" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43022>; Thu, 3 Dec 1992 10:48:53 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11601>; Thu, 3 Dec 1992 10:40:15 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12093>; Thu, 3 Dec 1992 10:30:22 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Thu, 3 Dec 1992 10:20:18 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11590>; Thu, 3 Dec 1992 10:19:50 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11544>; Thu, 3 Dec 1992 10:18:27 PST
Received: by mu.parc.xerox.com id <58373>; Thu, 3 Dec 1992 10:18:13 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0031BF45
In-Reply-to: <9212031441.AA23387@torque-wrench>
Message-ID: <92Dec3.101813pst.58373@mu.parc.xerox.com>
References: <9212031441.AA23387@torque-wrench>
Date:	Thu, 3 Dec 1992 10:18:13 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	ghudson@athena.mit.edu
cc:	MOO-Cows.PARC@xerox.com
Subject: Re: OUTPUT*FIX

> Date:	Thu, 3 Dec 1992 06:41:16 -0800
> From:	Greg Hudson <ghudson@athena.mit.edu>
> 
> A couple of commands I've noticed conspicuously missing in MOO are
> OUTPUTPREFIX and OUTPUTSUFFIX.  A look at the programmer's reference
> indicates that they would probably have to be treated in the server
> code, which is a bit unfortunate aesthetically, but they are crucial
> tools for intelligent clients.

A closer look at the programmer's manual shows that they do, in fact, exist
under the names PREFIX and SUFFIX.  They are first mentioned in the following
paragraph from chapter 2, `Command Parsing':

      Having thus broken the string into words, the server next checks
   to see if the first word names any of the three "built-in" commands:
   `.program', `PREFIX', or `SUFFIX'.  The first one of these is only
   available to programmers and the other two are intended for use by
   client programs; all three are described in the final chapter of this
   document, "Server Commands and Database Assumptions".  If the first
   word isn't one of the above, then we get to the usual case: a normal
   MOO command.

The relevant section from the final chapter is the following:

    Command-Output Delimiters
    -------------------------

       Every MOO network connection has associated with it two strings,
    the "output prefix" and the "output suffix".  Just before executing
    a command typed on that connection, the server prints the output
    prefix, if any, to the player.  Similarly, just after finishing the
    command, the output suffix, if any, is printed to the player.
    Initially, these strings are not defined, so no extra printing takes
    place.

       The `PREFIX' and `SUFFIX' commands are used to set and clear
    these strings.  They have the following simple syntax:

	 PREFIX  OUTPUT-PREFIX
	 SUFFIX  OUTPUT-SUFFIX

    That is, all text after the command name and any following spaces is
    used as the new value of the appropriate string.  If there is no
    non-blank text after the command string, then the corresponding
    string is cleared.

       These commands are intended for use by programs connected to the
    MOO, so that they can issue MOO commands and reliably determine the
    beginning and end of the resulting output.  For example, one
    editor-based client program sends this sequence of commands on
    occasion:

	 PREFIX >>MOO-Prefix<<
	 SUFFIX >>MOO-Suffix<<
	 @list OBJECT:VERB without numbers
	 PREFIX
	 SUFFIX

    The effect of which, in a LambdaCore-derived database, is to print
    out the code for the named verb preceded by a line containing only
    `>>MOO-Prefix<<' and followed by a line containing only
    `>>MOO-Suffix<<'.  This enables the editor to reliably extract the
    program text from the MOO output and show it to the user in a
    separate editor window.  There are many other possible uses.

       The built-in function `output_delimiters()' can be used by MOO
    code to find out the output prefix and suffix currently in effect on
    a particular network connection.

Finally, the description of the `output_delimiters()' function mentioned
above appears as follows in section 3.4.4, `Evaluation and Tasks':

     -- Function: list output_delimiters (obj PLAYER)
	 Returns a list of two strings, the current "output prefix" and
	 "output suffix" for PLAYER.  If PLAYER does not have an active
	 network connection, then `E_INVARG' is returned.  If either
	 string is currently undefined, the value `""' is used instead.
	 See the discussion of the `PREFIX' and `SUFFIX' commands in the
	 next chapter for more information about the output prefix and
	 suffix.

You're right, of course; such a feature is quite essential for certain kinds of
intelligent client operations.  They have always been in the server, since
before it was LambdaMOO.

	Pavel/Haakon

From xerox.com!eostrom.PARC Thu Dec  3 15:14:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "3" "December" "1992" "15:01:53" "-0800" "Erik Ostrom" "eostrom@hecate.gac.edu " nil "8" "moo-code.el" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Thu, 3 Dec 1992 15:14:31 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11684>; Thu, 3 Dec 1992 15:12:57 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11682>; Thu, 3 Dec 1992 15:08:44 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Thu, 3 Dec 1992 15:05:01 -0800
Received: from gacvx1.gac.edu ([138.236.1.1]) by alpha.xerox.com with SMTP id <11664>; Thu, 3 Dec 1992 15:04:20 PST
Received: from hecate (hecate.gac.edu) by gacvx1.gac.edu with PMDF#10127; Thu,
 3 Dec 1992 17:05 CST
Received: by hecate (NeXT-1.0 (From Sendmail 5.52)/GACnet-2.0-NeXT) id AA08302;
 Thu, 3 Dec 92 17:01:53 CST
X-NS-Transport-ID: 08002008D0FD0031C62B
Message-ID: <9212032301.AA08302@hecate>
Date:	Thu, 3 Dec 1992 15:01:53 -0800
From:	eostrom@hecate.gac.edu (Erik Ostrom)
Sender: eostrom.PARC@xerox.com
To:	MOO-Cows@parc.xerox.com
Subject: moo-code.el

Despite the lack of public demand, I've placed a file of emacs lisp code for
editing MOO-code on parcftp.xerox.com, in pub/MOO/contrib/moo-code.el.  It
works as a stand-alone editing mode, and with the version of mud.el
currently in pub/MOO/clients; I haven't tested it with any other versions,
but I suspect it will with little or no hacking.  Rough instructions for
making it work fairly nicely with that version of mud.el are included.

--Erik/JF

From dartmouth.edu!David.M.Aronchick Mon Dec  7 12:29:49 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "7" "December" "1992" "12:18:06" "-0800" "David.M.Aronchick@dartmouth.edu" "David.M.Aronchick@dartmouth.edu" nil "4" "Programmer'sCore in .txt" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43019>; Mon, 7 Dec 1992 12:29:44 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11607>; Mon, 7 Dec 1992 12:28:41 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11610>; Mon, 7 Dec 1992 12:21:38 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 7 Dec 1992 12:19:58 -0800
Received: from dartvax.dartmouth.edu ([129.170.16.4]) by alpha.xerox.com with SMTP id <11609>; Mon, 7 Dec 1992 12:18:36 PST
Received: from donner.dartmouth.edu by dartvax.dartmouth.edu (5.65+D4/4.5HUB)
	id AA11069; Mon, 7 Dec 92 15:18:09 -0500
X-NS-Transport-ID: 08002008D0FD0031FD75
Message-ID: <2784811@donner.Dartmouth.EDU>
Date:	Mon, 7 Dec 1992 12:18:06 -0800
From:	David.M.Aronchick@dartmouth.edu
To:	MOO-Cows@parc.xerox.com (MOO-Cows@parc.xerox.com)
Subject: Programmer'sCore in .txt

Does ANYONE have the programmers core(LambdaCoreProgMan.texinfo) in TeX or
.txt (.txt is preferred.) format?  I would very much appreciate if anyone
would send me a copy of that, and LambdaCoreUserMan.texinfo. in txt or
TeX(.txt is preferred).

From media-lab.media.mit.edu!asb Thu Dec 10 18:21:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "10" "December" "1992" "18:10:25" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "14" "Adminsitrative Procedures" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43032>; Thu, 10 Dec 1992 18:21:03 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12037>; Thu, 10 Dec 1992 18:19:27 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11952>; Thu, 10 Dec 1992 18:15:11 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 10 Dec 1992 18:10:47 -0800
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12048>; Thu, 10 Dec 1992 18:10:34 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA24685; Thu, 10 Dec 92 21:10:26 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD003246D1
Message-ID: <9212110210.AA24685@media-lab.mit.edu>
Date:	Thu, 10 Dec 1992 18:10:25 -0800
From:	asb@media-lab.media.mit.edu
To:	moo-cows@parc.xerox.com
Subject: Adminsitrative Procedures



I feel like we're trying to reinvent the administrative
wheel!  I could use some advice on how folks manage regular
administrative tasks, such as:

* How do you divide administrative tasks amongst the wizards?
* How do you decide whether someone gets more quota?
* How do you decide whether something gets publicly linked?
* How do you decide if an object can be installed in a public place?

All advice will be appreciated!

-- Amy

From stony-brook.scrc.symbolics.com!yduJ Thu Dec 10 21:05:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "10" "December" "1992" "21:00:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "43" "Adminsitrative Procedures" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43032>; Thu, 10 Dec 1992 21:05:33 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12038>; Thu, 10 Dec 1992 21:04:42 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12036>; Thu, 10 Dec 1992 21:02:10 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Thu, 10 Dec 1992 20:57:52 -0800
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <12036>; Thu, 10 Dec 1992 20:57:25 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1186035; 10 Dec 1992 23:57:35-0500
X-NS-Transport-ID: 08002008D0FD003248F5
In-Reply-to: <9212110210.AA24685@media-lab.mit.edu>
Message-ID: <19921211050004.2.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Thu, 10 Dec 1992 21:00:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	asb@media-lab.media.mit.edu, moo-cows@parc.xerox.com
Subject: Adminsitrative Procedures

    Date: Thu, 10 Dec 1992 21:10 EST
    From:	asb@media-lab.media.mit.edu



    I feel like we're trying to reinvent the administrative
    wheel!  I could use some advice on how folks manage regular
    administrative tasks, such as:

    * How do you divide administrative tasks amongst the wizards?

At LambdaMOO it's "whoever gets to it first" or "whoever takes the
smallest step backwards when potential volunteers are getting out of the
way".  Actually, I volunteered to do the registration administrivia
because I wanted us to go registration; when I'm out of town I get
someone else to do it for that week or so.

    * How do you decide whether someone gets more quota?

LambdaMOO has a complex system called the Architecture Review Board.
Check out "help quota-policy" on LambdaMOO.

    * How do you decide whether something gets publicly linked?

Currently we have the wizards decide if it's a REALLY public link like
onto the main core of the house.  However, links from within private
structures (even those linked onto the main core of the house) are under
the control of the owners of those structures.  We do *complain* when
they violate theme, but we don't do much more than that (well, besides
deny quota increases---that keeps 'em in line mostly).

    * How do you decide if an object can be installed in a public place?

Similarly.  I wrote the Generic Self-Cleaning room which ejects
"garbage" that's left lying about unless the object is in the @residents
of the room.  Most rooms in the core house are Self-Cleaning, which gets
rid of objects that aren't blessed, and so it takes a wizard to add it.
Or, the owner of the room, of course.  Mostly, we just complain a lot
about inappropriate objects.

    All advice will be appreciated!

    -- Amy

From cyber.widener.edu!Joshua.R.Poulson Fri Dec 11 07:06:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "11" "December" "1992" "06:51:35" "-0800" "Joshua.R.Poulson@cyber.widener.edu" "Joshua.R.Poulson@cyber.widener.edu" nil "28" "Reply to Adminsitrative Procedures" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43032>; Fri, 11 Dec 1992 07:05:59 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11680>; Fri, 11 Dec 1992 07:04:11 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11684>; Fri, 11 Dec 1992 07:00:37 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Fri, 11 Dec 1992 06:57:50 -0800
Received: from cyber.Widener.EDU ([147.31.1.13]) by alpha.xerox.com with SMTP id <11675>; Fri, 11 Dec 1992 06:57:21 PST
Received: from US*ATTMAIL*WIDE by widener-mg.Widener.EDU via QTFS with X.400;
 Fri, 11 Dec 92 09:51:41 -0500
X400-Trace: US*ATTMAIL*WIDE; arrival Fri, 11 Dec 92 09:51:35 -0500 action
 Relayed
P1-Message-ID: US*ATTMAIL*WIDE; 921211094404704-MTABWIDENER
UA-Content-ID: 921211094404704-
X-NS-Transport-ID: 08002008D0FD00324E74
In-Reply-to: <9212110210.AA24685@media-lab.mit.edu>
Message-ID: <921211094404704-MTABWIDENER*Joshua.R.Poulson@cyber.Widener.EDU>
Date:	Fri, 11 Dec 1992 06:51:35 -0800
From:	Joshua.R.Poulson@cyber.widener.edu
To:	moo-cows@parc.xerox.com
Subject: Reply to Adminsitrative Procedures

>I feel like we're trying to reinvent the administrative
>wheel!  I could use some advice on how folks manage regular
>administrative tasks, such as:
>* How do you divide administrative tasks amongst the wizards?

It tends to be that each Wizard has skills to offer the Moo, and the duties
should be divided so people are doing what they enjoy doing.  Tasks that no
one likes doing can be handled on a voluntary or rotational basis.

>* How do you decide whether someone gets more quota?

Generally quota can be handled by a couple of checkpoints. Numbers than seem
to work nicely are 20 for the first point and 100 for the next. Most people
realize that going beyond is a difficult prospect. :)

>* How do you decide whether something gets publicly linked?

On a theme-based Moo, this is fairly easy. Only theme-based items should be
easily found. :)

>* How do you decide if an object can be installed in a public place?

aSame as above.

This is all thumbnail stuff, for a complete statement of policy it would take
some time and some consulting with the other Wizards. :)

--JRP [Shirgall@all over the place]

From lehigh.edu!tfv0 Fri Dec 11 13:15:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "11" "December" "1992" "12:51:59" "-0800" "Theodore F Vaida ][" "tfv0@lehigh.edu " nil "45" "How to execute a string as if the player had entered it at the" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43032>; Fri, 11 Dec 1992 13:15:21 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11739>; Fri, 11 Dec 1992 13:14:33 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11731>; Fri, 11 Dec 1992 13:10:29 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Fri, 11 Dec 1992 13:08:33 -0800
Received: from ns3.CC.Lehigh.EDU ([128.180.2.37]) by alpha.xerox.com with SMTP id <11739>; Fri, 11 Dec 1992 13:08:02 PST
Received: by ns3.CC.Lehigh.EDU id AA57913
  (5.67a/IDA-1.5); Fri, 11 Dec 1992 15:52:02 -0500
X-NS-Transport-ID: 08002008D0FD003256A3
Message-ID: <199212112052.AA57913@ns3.CC.Lehigh.EDU>
Date:	Fri, 11 Dec 1992 12:51:59 -0800
From:	tfv0@lehigh.edu (Theodore F Vaida ][)
To:	moo-cows@parc.xerox.com
Subject: How to execute a string as if the player had entered it at the

I would like to be able to make a string be executed as if the player
had entered it at the command line.  I have an alias->dealiaser set of
commands that run under the player when it trys to run a "huh2".  

eval("some thing");

only makes the line prentend to run as if it was in a program... si it
possible to have a line parsed and executed as if the player typed it?
(this is a fairly large security hole i'm sure if it isnt kep under
strict control...)

i have the latest server and the latest core (last announcemtn on
MOO-Cows that is...)

thanks in advance
---------=======================================================---------
                  ->POLAR CAPS<- or tfv0@lehigh.edu
Student Konsultant Making the world safe for computing!
"Never before have we owed so little to so few..."- R.T.Folk
"One must not confuse John Dunne's famous quote `No man is an Island' with
 New York Telephone's `We're all connected'" - Dad
"Trust no one, and be honest with all"  _Claudius_the_God_, and Dad
   Paranoid, but it'll keep you out of trouble...
---------=======================================================---------

Public PGP encryption key follows:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQCNAisNQC8AAAED/jWn7LpfQtD7nMpW5RyozsriXhkpU6j6z4FDILYVHhY5AMx4
Z35+t4ONNlN+LsqohqJWjpVn3CRryVSFiQqCtnp/QkXq0ltVk49Q+zqtnBjVS4cE
BCJGwDfUKQ+vcP1g/ab8Fn4a1OxmZSXxTvwCoq6aggsC+bq19+01B9Ne0AbRAAUR
tCNUaGVvZG9yZSBGLiBWYWlkYSA8dGZ2MEBsZWhpZ2guZWR1PokAlQIFECsNQc81
J04nVqoK1QEBsAAD/0hDsD82kiA5JDCIe+wVVO7zlAVFwCqPJdgFob3AYOyOiyKW
iem8ycsbfcEAvvPZhfr3LA2wIeBaeyKBPJhfvxWiAak2omoFEGrArDN5krqXM1IE
/keGzEZrj3d8x1EcMSWrnTStZoONIqaaOqF69IXtkic0phn70qb7OwsmrggbiQCV
AgUQKw1HQe01B9Ne0AbRAQHaRQP+KKVm5lqKPsTcxsupJNjJ5T4OQYl7qqu3/cZy
3gTsgApeR3dkrYMC0/9HWb81xORb9caeaCFb53frTYa15UtRaECMXiNYopJoz2Ui
JM/+GVskDQ1lXntDH9hC7dMvbt/mJHVmEdfDG6I/GfHK8WBVtnjb3+TA6s5V86Hr
9HF4E0i0K1RoZW9kb3JlIEYuIFZhaWRhIDxwY2FwQGJpZmYuY2MubGVoaWdoLmVk
dT4=
=wi6W
-----END PGP PUBLIC KEY BLOCK-----


From sco.com!chrisn Fri Dec 11 13:28:01 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "11" "December" "1992" "13:19:25" "-0800" "\"The Horror, The Horror\"" "chrisn@sco.com" nil "17" "Mobiles/NPC/Robots on MOO" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43032>; Fri, 11 Dec 1992 13:27:51 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11746>; Fri, 11 Dec 1992 13:27:04 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11748>; Fri, 11 Dec 1992 13:24:21 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Fri, 11 Dec 1992 13:20:54 -0800
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <11742>; Fri, 11 Dec 1992 13:20:26 PST
Received: from sco.sco.COM by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA22465; Fri, 11 Dec 92 16:20:09 -0500
Received: from devsco.sco.COM by sco.sco.COM
	id aa10602; Fri, 11 Dec 92 13:21:04 PST
X-Mailer: SCO System V Mail (version 3.2)
X-NS-Transport-ID: 08002008D0FD003256F8
Message-ID: <9212111319.aa22566@devsco.sco.COM>
Date:	Fri, 11 Dec 1992 13:19:25 -0800
From:	"The Horror, The Horror" <chrisn@sco.com>
To:	moo-cows@parc.xerox.com
Subject: Mobiles/NPC/Robots on MOO


Howdy,

Our MOO has some areas where an NPC (non-player creature) would be handy,
and example would be an automated bartender/shopkeeper or talking statue,
etc etc.

Does anyone have any suggestions on using the MOO code to create
NPCs? Due to the 'tick' limitation, it seems MOO is not set up to
handle 'daemon' types of activities.

I have some basic robot capable clients I can connect to the MOO, but 
would prefer to build the NPCs into the database using MOO code.

Thanks,

ccn

From parc.xerox.com!pavel Mon Dec 14 15:17:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "15:08:02" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "14" "Re: Mobiles/NPC/Robots on MOO" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 15:17:44 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11683>; Mon, 14 Dec 1992 15:16:39 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11691>; Mon, 14 Dec 1992 15:13:39 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Mon, 14 Dec 1992 15:11:20 -0800
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11681>; Mon, 14 Dec 1992 15:08:25 PST
Received: by mu.parc.xerox.com id <58372>; Mon, 14 Dec 1992 15:08:16 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD003279DE
In-Reply-to: <9212111319.aa22566@devsco.sco.COM>
Message-ID: <92Dec14.150816pst.58372@mu.parc.xerox.com>
References: <9212111319.aa22566@devsco.sco.COM>
Date:	Mon, 14 Dec 1992 15:08:02 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	chrisn@sco.com
cc:	moo-cows@parc.xerox.com
Subject: Re: Mobiles/NPC/Robots on MOO

> Date:	Fri, 11 Dec 1992 13:19:25 -0800
> From:	"The Horror, The Horror" <chrisn@sco.com>
> 
> Does anyone have any suggestions on using the MOO code to create
> NPCs? Due to the 'tick' limitation, it seems MOO is not set up to
> handle 'daemon' types of activities.

This isn't so.  You can either use `fork' to spawn tasks that wake up some time
in the future and do one thing, or else use `suspend()' to have a single task
last forever, suspending its execution each time before it runs out of ticks.
There are many, many daemon tasks running on LambdaMOO for a variety of
purposes.

	Pavel

From parc.xerox.com!pavel Mon Dec 14 15:39:47 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "15:06:00" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "12" "Re: How to execute a string as if the player had entered it at the" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 15:39:38 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11680>; Mon, 14 Dec 1992 15:38:56 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11664>; Mon, 14 Dec 1992 15:11:19 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 15:09:02 -0800
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11662>; Mon, 14 Dec 1992 15:06:25 PST
Received: by mu.parc.xerox.com id <58372>; Mon, 14 Dec 1992 15:06:15 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD003279CB
In-Reply-to: <199212112052.AA57913@ns3.CC.Lehigh.EDU>
Message-ID: <92Dec14.150615pst.58372@mu.parc.xerox.com>
References: <199212112052.AA57913@ns3.CC.Lehigh.EDU>
Date:	Mon, 14 Dec 1992 15:06:00 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	tfv0@lehigh.edu
cc:	moo-cows@parc.xerox.com
Subject: Re: How to execute a string as if the player had entered it at the

> Date:	Fri, 11 Dec 1992 12:51:59 -0800
> From:	tfv0@lehigh.edu (Theodore F Vaida ][)
> 
> I would like to be able to make a string be executed as if the player
> had entered it at the command line.

There is no built-in way to do this, though it is possible to write MOO code
that does a pretty good job of simulating it.  See the code on LambdaMOO for
the generic puppet's :do verb.  There's still a problem with !x verbs, but it
might still work out well enough for your purposes.

	Pavel

From wg7j.ece.orst.edu!g6phf Mon Dec 14 15:52:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "08:06:47" "-0800" "g6phf@wg7j.ece.orst.edu" "g6phf@wg7j.ece.orst.edu" nil "5" "generic guests" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 15:52:55 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11696>; Mon, 14 Dec 1992 15:51:09 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11687>; Mon, 14 Dec 1992 15:49:43 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 15:47:53 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11676>; Mon, 14 Dec 1992 15:47:06 PST
Received: from wg7j.ECE.ORST.EDU ([128.193.48.123]) by alpha.xerox.com with SMTP id <11673>; Mon, 14 Dec 1992 15:12:52 PST
X-NS-Transport-ID: 08002008D0FD003279D6
Message-ID: <2732@wg7j.ECE.ORST.EDU>
Date:	Mon, 14 Dec 1992 08:06:47 -0800
From:	g6phf@wg7j.ece.orst.edu
To:	moo-cows.PARC@xerox.com
Subject: generic guests

 Forgive my ignorance, could someone please explain, how I get the generic
guest login to work, e.g. like on lambda with the coloured guests. I am using
a recent core.db from parcftp, and have just managed to get 1.7 working on
my 386 pc at home.
 Thanks in advance.

From media-lab.media.mit.edu!asb Mon Dec 14 16:37:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "16:30:34" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" "<9212150030.AA10395@media-lab.mit.edu>" "23" "Re: generic guests" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 16:37:39 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11690>; Mon, 14 Dec 1992 16:37:17 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11689>; Mon, 14 Dec 1992 16:34:08 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 16:32:25 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11690>; Mon, 14 Dec 1992 16:31:55 PST
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11699>; Mon, 14 Dec 1992 16:30:53 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA10395; Mon, 14 Dec 92 19:30:35 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD00327B83
In-Reply-to: "Your message of \"Mon, 14 Dec 92 08:06:47 PST.\"
             <2732@wg7j.ECE.ORST.EDU> bhe light"
Message-ID: <9212150030.AA10395@media-lab.mit.edu>
Date:	Mon, 14 Dec 1992 16:30:34 -0800
From:	asb@media-lab.media.mit.edu
To:	g6phf@wg7j.ece.orst.edu
cc:	moo-cows.PARC@xerox.com, asb@media-lab.media.mit.edu
Subject: Re: generic guests


Your message dated: Mon, 14 Dec 92 08:06:47 PST
>  Forgive my ignorance, could someone please explain, how I get the generic
> guest login to work, e.g. like on lambda with the coloured guests. I am using
> a recent core.db from parcftp, and have just managed to get 1.7 working on
> my 386 pc at home.
>  Thanks in advance.

To make a guest, make a player, and then change its parent to $guest.
You must make one called "Guest" before you make all the colored ones.
I also chown the player object to me, (guests don't own themselves.)
(Is that a good idea?)

If you want to change the guest description, don't forget to
change the slot default_description, rather than just changing
the description.

While we're on the subject:
Can someone please tell me what the "responsible" slot does?
In the October release of the core, $guest.responsible
has a whole bunch of junk on it.

-- Amy

From parc.xerox.com!pavel Mon Dec 14 17:14:48 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "17:08:32" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "12" "Re: generic guests" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 17:14:42 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11705>; Mon, 14 Dec 1992 17:13:16 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11699>; Mon, 14 Dec 1992 17:11:32 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 17:09:53 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11699>; Mon, 14 Dec 1992 17:09:33 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11701>; Mon, 14 Dec 1992 17:08:39 PST
Received: by mu.parc.xerox.com id <58372>; Mon, 14 Dec 1992 17:08:37 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00327C59
In-Reply-to: <9212150030.AA10395@media-lab.mit.edu>
Message-ID: <92Dec14.170837pst.58372@mu.parc.xerox.com>
References: <2732@wg7j.ECE.ORST.EDU> <9212150030.AA10395@media-lab.mit.edu>
Date:	Mon, 14 Dec 1992 17:08:32 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	asb@media-lab.media.mit.edu
cc:	g6phf@wg7j.ece.orst.edu, moo-cows.PARC@xerox.com
Subject: Re: generic guests

> Date:	Mon, 14 Dec 1992 16:30:34 -0800
> From:	asb@media-lab.media.mit.edu
> 
> Can someone please tell me what the "responsible" slot does?
> In the October release of the core, $guest.responsible
> has a whole bunch of junk on it.

This is the slot used by the @check and @paranoid commands for spoof-detection.
It contains the callers() lists for the last `n' calls to your :tell.  Sorry
about the grunge in the core.

	Pavel

From cs.stanford.edu!crew Mon Dec 14 17:19:19 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "17:12:29" "-0800" "Roger Crew" "crew@cs.stanford.edu" nil "17" "Re: How to execute a string as if the player had entered it at the" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 17:19:12 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11700>; Mon, 14 Dec 1992 17:17:59 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11710>; Mon, 14 Dec 1992 17:16:23 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 17:14:07 -0800
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11700>; Mon, 14 Dec 1992 17:13:01 PST
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA28728; Mon, 14 Dec 92 17:12:29 PST
X-NS-Transport-ID: 08002008D0FD00327C94
In-Reply-to: "Your message of \"Mon, 14 Dec 92 15:06:00 PST.\"
             <92Dec14.150615pst.58372@mu.parc.xerox.com> be che"
Message-ID: <9212150112.AA28728@Xenon.Stanford.EDU>
Date:	Mon, 14 Dec 1992 17:12:29 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
cc:	tfv0@lehigh.edu
Subject: Re: How to execute a string as if the player had entered it at the

>   There's still a problem with !x verbs, but it
>   might still work out well enough for your purposes.

Well, you *could* write a wizardly verb to take an arbitrary verb, set
it +x, chown it to a wizard, and set_verb_code() to add some code to
the beginning of the verb that would in turn restore the original verb
code, reset the x flag, restore the original ownership, and finally
set_task_perms(verbowner).  Forget to do any of these things and/or
not put adequate protection on said wizardly verb and you've got
yourself a monster security hole.

Think of this as the next stage of psychosis beyond LambdaCore's
$code_utils:eval_d().
--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

From cs.stanford.edu!crew Mon Dec 14 18:17:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "18:12:54" "-0800" "Roger Crew" "crew@cs.stanford.edu" nil "24" "Re: generic guests" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 18:17:04 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11751>; Mon, 14 Dec 1992 18:16:30 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11737>; Mon, 14 Dec 1992 18:14:58 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 18:13:23 -0800
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <11751>; Mon, 14 Dec 1992 18:13:04 PST
Received: from LOCALHOST.Stanford.EDU by Xenon.Stanford.EDU (4.1/25-XENON-eef) id AA03347; Mon, 14 Dec 92 18:12:55 PST
X-NS-Transport-ID: 08002008D0FD00327D8A
In-Reply-to: "Your message of \"Mon, 14 Dec 92 16:30:34 PST.\"
             <9212150030.AA10395@media-lab.mit.edu>ever"
Message-ID: <9212150212.AA03347@Xenon.Stanford.EDU>
Date:	Mon, 14 Dec 1992 18:12:54 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	moo-cows@parc.xerox.com
Subject: Re: generic guests

>   To make a guest, make a player, and then change its parent to $guest.

Life might be slightly easier if you @create a child of $guest and
then @detoad it --- given the current popularity of @newt/@denewt,
this is probably one of the few real uses left for @detoad (*)
@detoad (really $wiz_utils:set_player) understood about $guest
children last I checked so the ownership issue should take care of
itself (as long as you haven't recycled $hacker ... if you have, lots
of things in LambdaCore will break).

>   You must make one called "Guest" before you make all the colored ones.
>   I also chown the player object to me, (guests don't own themselves.)
>   (Is that a good idea?)

The reason for guests not owning themselves is so that random
people can't login and do arbitrary things to your guest's properties.
--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

(*) still remembers the days when @toad/@detoad were added as a
matter of completeness, not because anyone thought they would actually
get used.  sigh...

From stony-brook.scrc.symbolics.com!yduJ Mon Dec 14 21:32:42 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "14" "December" "1992" "21:20:00" "-0800" "Judy Anderson" "yduJ@stony-brook.scrc.symbolics.com" nil "11" "Re: generic guests" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 14 Dec 1992 21:32:33 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11743>; Mon, 14 Dec 1992 21:29:14 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11728>; Mon, 14 Dec 1992 21:22:47 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 14 Dec 1992 21:18:52 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11711>; Mon, 14 Dec 1992 21:18:32 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by alpha.xerox.com with SMTP id <11711>; Mon, 14 Dec 1992 21:17:48 PST
Received: from JACKS-PLACE.SHARON.SYMBOLICS.COM ([128.81.253.14]) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 1187467; 15 Dec 1992 00:17:41-0500
X-NS-Transport-ID: 08002008D0FD00327F63
In-Reply-to: <9212150030.AA10395@media-lab.mit.edu>
Message-ID: <19921215052035.1.YDUJ@JACKS-PLACE.sharon.symbolics.com>
Date:	Mon, 14 Dec 1992 21:20:00 -0800
From:	Judy Anderson <yduJ@stony-brook.scrc.symbolics.com>
To:	asb@media-lab.media.mit.edu, g6phf@wg7j.ece.orst.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: generic guests

    Date: Mon, 14 Dec 1992 19:30 EST
    From:	asb@media-lab.media.mit.edu

    To make a guest, make a player, and then change its parent to $guest.
    You must make one called "Guest" before you make all the colored ones.
    I also chown the player object to me, (guests don't own themselves.)
    (Is that a good idea?)

No.  Don't let your guests be owned by a wizard or they can get into any
room they want, @lock or no.  Better to have them owned by $hacker than
any person who owns real estate.

From xerox.com!parc.xerox.com.PARC Tue Dec 15 03:20:22 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "15" "December" "1992" "03:04:50" "-0800" "Byron Montgomerie" "byron@cs.mun.ca" nil "16" "$guest creation" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43016>; Tue, 15 Dec 1992 03:20:19 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11744>; Tue, 15 Dec 1992 03:19:38 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11739>; Tue, 15 Dec 1992 03:16:06 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Tue, 15 Dec 1992 03:06:10 -0800
Received: from garfield.cs.mun.ca ([134.153.1.1]) by alpha.xerox.com with SMTP id <11731>; Tue, 15 Dec 1992 03:05:48 PST
Received: by garfield.cs.mun.ca id <45232>; Tue, 15 Dec 1992 07:35:05 -0330
X-NS-Transport-ID: 08002008D0FD00328202
Message-ID: <92Dec15.073505nst.45232@garfield.cs.mun.ca>
Date:	Tue, 15 Dec 1992 03:04:50 -0800
From:	Byron Montgomerie <byron@cs.mun.ca>
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: $guest creation

If I might make a suggestion, how about adding a help guests to wiz-index in
the next core so that this question of how to set up guests won't keep
recurring.  Or better yet, instead of having to do a make-player or whatever,
set it up so that creating a guest is one verb. This would involve a few lines
of code at worst I think.

ie. @make-guest Drunken_Guest

 Byron... (Tarod@Lambda)
 ___________________________________________________________________________
|     ///    "Byron Montgomerie"  Internet: byron@odie.cs.mun.ca       ///  |
| \\\///      "Does anybody here remember Vera Lynn?               \\\///   |
|  \///        How she said that we would meet again,               \///    |
|  Amiga       some sunny day..." -- Pink Floyd --                 Amiga    |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From steamer.clam.com!jeff Tue Dec 15 07:18:41 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "15" "December" "1992" "07:09:25" "-0800" "Jeff d'Arcy" "jeff@steamer.clam.com " nil "7" "Re: generic guests" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43016>; Tue, 15 Dec 1992 07:18:36 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11775>; Tue, 15 Dec 1992 07:18:05 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11780>; Tue, 15 Dec 1992 07:16:27 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Tue, 15 Dec 1992 07:12:07 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11765>; Tue, 15 Dec 1992 07:11:43 PST
Received: from steamer.clam.com ([192.124.136.113]) by alpha.xerox.com with SMTP id <11771>; Tue, 15 Dec 1992 07:10:49 PST
Received: by steamer.clam.com (AIX 3.2/UCB 5.64/4.03)
          id AA113105; Tue, 15 Dec 1992 10:09:25 -0500
X-NS-Transport-ID: 08002008D0FD00328496
Message-ID: <9212151509.AA113105@steamer.clam.com>
Date:	Tue, 15 Dec 1992 07:09:25 -0800
From:	jeff@steamer.clam.com (Jeff d'Arcy)
To:	asb@media-lab.media.mit.edu, g6phf@wg7j.ece.orst.edu
cc:	moo-cows.PARC@xerox.com
Subject: Re: generic guests


The .responsible property is used to detect spoofing.  It contains the
information necessary to determine who was responsible for the last twenty
or so invocations of the player's :tell verb.  I don't remember how to
turn this recording on/off or anything, though.

	jeff

From sco.com!chrisn Tue Dec 15 11:02:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "15" "December" "1992" "10:52:52" "-0800" "\"The Horror, The Horror\"" "chrisn@sco.com" nil "7" "NPCs" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43016>; Tue, 15 Dec 1992 11:02:51 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11619>; Tue, 15 Dec 1992 11:01:41 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11591>; Tue, 15 Dec 1992 10:58:40 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 15 Dec 1992 10:54:10 -0800
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <11773>; Tue, 15 Dec 1992 10:53:30 PST
Received: from sco.sco.COM by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA00669; Tue, 15 Dec 92 13:53:26 -0500
Received: from devsco.sco.COM by sco.sco.COM
	id aa16048; Tue, 15 Dec 92 10:54:50 PST
X-Mailer: SCO System V Mail (version 3.2)
X-NS-Transport-ID: 08002008D0FD003289AA
Message-ID: <9212151052.aa06024@devsco.sco.COM>
Date:	Tue, 15 Dec 1992 10:52:52 -0800
From:	"The Horror, The Horror" <chrisn@sco.com>
To:	MOO-Cows@parc.xerox.com
Subject: NPCs


Thanks to all who responded.
I have written a quickie NPC, spot the wonder dog, who is even now
wandering through the halls of our MOO. Heaven help the player who
mistreats old spot...

ccn

From theory.mankato.msus.edu!nop Wed Dec 16 17:44:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "16" "December" "1992" "17:36:47" "-0800" "Jay A. Carlson" "nop@theory.mankato.msus.edu " nil "12" "Text into Moo (my hack for now)" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43021>; Wed, 16 Dec 1992 17:44:22 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12494>; Wed, 16 Dec 1992 17:43:48 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12251>; Wed, 16 Dec 1992 17:40:17 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Wed, 16 Dec 1992 17:36:41 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12227>; Wed, 16 Dec 1992 17:36:24 PST
Received: from theory.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <12493>; Wed, 16 Dec 1992 17:35:52 PST
Received: by theory.mankato.msus.edu (5.65/DEC-Ultrix/4.3)
	id AA02926; Wed, 16 Dec 1992 19:36:47 -0600
X-NS-Transport-ID: 08002008D0FD0032A72C
In-Reply-to: "Jonathan Bradshaw's message of Wed, 16 Dec 1992 16:02:41 PST <9212170002.AA16577@nova.decio.nd.edu>"
Message-ID: <9212170136.AA02926@theory.mankato.msus.edu>
Date:	Wed, 16 Dec 1992 17:36:47 -0800
From:	nop@theory.mankato.msus.edu (Jay A. Carlson)
To:	jonathan@nova.decio.nd.edu
cc:	MOO-Cows.PARC@xerox.com
Subject: Text into Moo (my hack for now)

> (Next... time to access the WEATHER ... <grin>)

Just for those of you who haven't been caught up in the ElseMOO
madness, connect to JaysHouseMOO at theory.cs.mankato.msus.edu 1709
where we've been going a little crazy with o_n_c() with everything
from a gopher client to SMTP to MOO networking.

And there's a ASCII weather map of Minnesota in the living room, child
of the generic gopher note.

Jay Carlson
nop@theory.cs.mankato.msus.edu

From xerox.com!PARC.xerox.com.PARC Thu Dec 17 13:17:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "17" "December" "1992" "13:08:41" "-0800" "\"Carl Gruden\"" "g-gruden@cs.yorku.ca" nil "9" "Setting up a MOO" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43021>; Thu, 17 Dec 1992 13:16:53 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11615>; Thu, 17 Dec 1992 13:16:19 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11618>; Thu, 17 Dec 1992 13:12:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 17 Dec 1992 13:10:21 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11614>; Thu, 17 Dec 1992 13:09:50 PST
Received: from nexus.yorku.ca ([130.63.9.66]) by alpha.xerox.com with SMTP id <11615>; Thu, 17 Dec 1992 13:09:18 PST
Received: from sasquatch.cs.yorku.ca ([130.63.9.18]) by nexus.yorku.ca with SMTP id <9223>; Thu, 17 Dec 1992 16:08:54 -0500
Received: from hermes.cs.yorku.ca by cs.yorku.ca (4.0/SMI-4.1)
	id AA19178; Thu, 17 Dec 92 16:08:41 EST
Received: by hermes.cs.yorku.ca (4.1/SMI-4.1)
	id AA10006; Thu, 17 Dec 92 16:08:40 EST
X-NS-Transport-ID: 08002008D0FD0032B63D
XNS-Originator: PARC.xerox.com.PARC@Xerox.com
Errors-to: PARC.xerox.com.PARC@xerox.com
Message-ID: <9212172108.AA19178@cs.yorku.ca>
Date:	Thu, 17 Dec 1992 13:08:41 -0800
From:	"Carl Gruden" <g-gruden@cs.yorku.ca>
Sender: <@nexus.yorku.ca:g-gruden@cs.yorku.CA>
To:	MOO-Cows.PARC@xerox.com, g-gruden@cs.yorku.ca
Subject: Setting up a MOO

I've just recently installed a MOO server, running version 1.7 with
the core Lambda db.  I'm interested in developing a medieval type
theme which is a bit of a fantasy type land, with combatscenarios
etc...

Does anyone have any pointers as to where to look for, or what to add
to the core db towards this end?

Carl

From media.mit.edu!asb Fri Dec 18 14:00:40 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "December" "1992" "13:49:40" "-0800" "asb@media.mit.edu" "asb@media.mit.edu" nil "17" "Janitors" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Fri, 18 Dec 1992 14:00:35 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12576>; Fri, 18 Dec 1992 13:59:17 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12569>; Fri, 18 Dec 1992 13:55:58 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Fri, 18 Dec 1992 13:50:08 -0800
Received: from media.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12563>; Fri, 18 Dec 1992 13:49:43 PST
Received: by media.mit.edu (5.57/DA1.0.4.amt)
	id AA06603; Fri, 18 Dec 92 16:49:41 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD0032CB8C
Message-ID: <9212182149.AA06603@media.mit.edu>
Date:	Fri, 18 Dec 1992 13:49:40 -0800
From:	asb@media.mit.edu
To:	moo-cows@parc.xerox.com
Subject: Janitors


On MediaMOO, we have officially changed "wizards" to "janitors."  I got tired
real fast of people asking for things "on bended knee," throwing around
chivalraic language, and being generally obsequious, and proposed the name
change almost in jest -- and we all decided to really do it!

I think the change has had lots of positive ramifications-- what you call
something changes how you think about it.  Janitors have the keys to
everything, but do their best not to stick their noses into other people's
business.  Janitors work hard, and are under-rewarded for their efforts.
Janitors clean up other people's messes, but a sensitive community
tries not to overburden them by being messy.  (Of course, RL janitors
get PAID!  :-)

I recommend the name change to anyone administrating a MOO.

-- Amy

From ee.ualberta.ca!daum Fri Dec 18 14:11:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "December" "1992" "14:02:58" "-0800" "Comrade Porcupine" "daum@ee.ualberta.ca" nil "22" "Re: Janitors" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Fri, 18 Dec 1992 14:11:24 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11645>; Fri, 18 Dec 1992 14:10:23 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12571>; Fri, 18 Dec 1992 14:07:44 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Fri, 18 Dec 1992 14:04:43 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12566>; Fri, 18 Dec 1992 14:04:21 PST
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <12576>; Fri, 18 Dec 1992 14:03:48 PST
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA05962; Fri, 18 Dec 92 15:02:59 -0700
Full-Name: Comrade Porcupine
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD0032CBB3
In-Reply-to: "<9212182149.AA06603@media.mit.edu>; from \"asb@media.mit.edu\" at Dec 18, 92 1:49 pmc 92here is "
Message-ID: <92Dec18.140348pst.12576@alpha.xerox.com>
Date:	Fri, 18 Dec 1992 14:02:58 -0800
From:	Comrade Porcupine <daum@ee.ualberta.ca>
To:	moo-cows.PARC@xerox.com
Subject: Re: Janitors

> 
> 
> On MediaMOO, we have officially changed "wizards" to "janitors."  I got tired
> real fast of people asking for things "on bended knee," throwing around
> chivalraic language, and being generally obsequious, and proposed the name
> change almost in jest -- and we all decided to really do it!

	We have been doing this very same thing on PlayhouseMOO for about a
month or so now.
> 
> I think the change has had lots of positive ramifications-- what you call
> something changes how you think about it.  Janitors have the keys to
> everything, but do their best not to stick their noses into other people's
> business.  Janitors work hard, and are under-rewarded for their efforts.
> Janitors clean up other people's messes, but a sensitive community
> tries not to overburden them by being messy.  (Of course, RL janitors
> get PAID!  :-)
> 
	Of course, on PlayhouseMOO the name change also came in sync with
our policy, which is "wizards hands off" (unless it affects the physical
health of the MOO, such as wiz bit hacking, or RL crimes like harassment or
whatever)

From cs.stanford.edu!crew Fri Dec 18 15:14:49 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "December" "1992" "15:08:25" "-0800" "Roger Crew" "crew@cs.stanford.edu" nil "113" "Re: Request for power testers" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Fri, 18 Dec 1992 15:14:39 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12574>; Fri, 18 Dec 1992 15:13:47 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11659>; Fri, 18 Dec 1992 15:12:04 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Fri, 18 Dec 1992 15:08:43 -0800
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <12565>; Fri, 18 Dec 1992 15:08:22 PST
Received: from LOCALHOST by Xenon.Stanford.EDU with SMTP (5.61+IDA/25-CS-eef) id AA14212; Fri, 18 Dec 92 15:08:25 -0800
X-NS-Transport-ID: 08002008D0FD0032CCFB
In-Reply-to: "Your message of \"Thu, 17 Dec 92 14:47:04 PST.\"
             <92Dec17.144709pst.58372@mu.parc.xerox.com> for sy"
Message-ID: <9212182308.AA14212@Xenon.Stanford.EDU>
Date:	Fri, 18 Dec 1992 15:08:25 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	Pavel Curtis <Pavel@parc.xerox.com>
cc:	moo-cows@parc.xerox.com
Subject: Re: Request for power testers

Looking over the new code, if I'm reading things right, it appears that

TRY
  <try-body>
FINALLY
  <finally-portion>
ENDTRY

is a form of unwind-protect, i.e., the finally-portion of the body
always gets executed no matter what errors occur in the main try-body,
unless something does a kill_task() or we run out of ticks.

It looks to me like it would be fairly straightforward to subtract n
ticks from the clock on entering the try-body (in EOP_TRY_FINALLY).
At the end of the try-body (EOP_END_TRY_FINALLY) or any unwinding of
the stack one would then restore those n ticks.  Then the
finally-portion would be guaranteed at least n ticks to run even if
the try-body runs out of ticks.  The idea here is that if there are
fewer than n ticks left when you get to the beginning of the TRY, then
you abort immediately with "out of ticks" (thus penalizing you for
beeing greedy --- one only reserves what one thinks one will need).

The handler entry on the stack would have to include a
number-of-ticks-to-restore field and you'd also be keeping track of
the total number of reserved ticks in any given task so that if the
task suspends, the reserved ticks can be subtracted from the 15000 (?)
that the newly-resumed task would ordinarily get when it resumes.
This way

(*) a background task would never be running with a tick allowance
   higher than 15000.

(*) once you reserve n ticks, those ticks stay reserved whether or not
   the task later suspends --- the ticks only go back when the handler
   gets popped off the stack (i.e., on a normal exit for the try body,
   or an exception that reaches that handler)

n could just be a constant (e.g., 500), or you could modify the syntax 
slightly:

TRY
  ...
FINALLY (300)
  (i.e, we'll say this section needs no more than 300 ticks to run)
  ...
ENDTRY


Another thought would be that the usual kill_task() be reinterpreted:

   Set ticks_left to 0 so that the next time the task attempts
   to run it dies.  Also set a flag to indicate that this really was a
   kill_task and not an ordinary out-of-ticks, so that we don't get a 
   backtrace.

The difference from before is that any pending finally sections will run 
(with only the allotment of ticks they had reserved on try-entry) to do
any cleanups that might be necessary.  

This would mostly fix the current problem in which any player's code 
I call can screw me by doing one of the following:

   1) divide_by_zero or some other random error 
         catchable by TRY...EXCEPT/FINALLY
   2) exhausting the tick/second clock
         would be catchable if TRY...FINALLY can reserve ticks
   3) issuing a kill_task(task_id())
         catchable if TRY...FINALLY can reserve ticks and
         kill_task() is simply a ticks_left := 0 operation;
   4) suspend() 
         (needs more thought ... see below)

We might conceivably still need a terminate-with-extreme-prejuidice function
for use by wizards.

vaporize_task() 
   set the tick clock to some suitably negative-infinite number. 
   Task dies immediately and no finally-sections get to run.
   (granted, this could be implemented the way kill-task currently is, since
   the effect is the same).


About catching suspends:

Given the above, one could try to fake this with
  TRY ... FINALLY (15000) ... ENDTRY 
since any suspend would result in an out-of-ticks that would
then unwind back to this finally section.  Admittedly, what
you really want is a way to get the finally clause to execute 
*before* the suspension takes place.  e.g.,
 TRY ... ONSUSPEND ... ENDTRY

An alternative would be a construct making suspend() a no-op for 
the duration of a particular statement or expression.

A third alternative would be a construct allowing one to specify
suspend hooks and resume hooks, e.g.,

CRITICAL
  <statements>
ONSUSPEND
  <prepare-for-hibernation code...>
ONRESUME
  <look-at-new-state-of-the-world code...>
ENDCRITICAL

it's rather annoying that statements and expressions are different
things, since we'd really need one of these constructs for each.

--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

From xerox.com!parc.xerox.com.PARC Fri Dec 18 17:05:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "December" "1992" "16:59:07" "-0800" "\"Jon Brazelton, Residence Hall Coordinator\"" "JPB7946%TNTECH.bitnet@cunyvm.cuny.edu" nil "14" "Info on other MOOs" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Fri, 18 Dec 1992 17:05:14 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12588>; Fri, 18 Dec 1992 17:04:25 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12598>; Fri, 18 Dec 1992 17:02:28 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Fri, 18 Dec 1992 16:59:32 -0800
Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <12587>; Fri, 18 Dec 1992 16:59:20 PST
Received: from TNTECH.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2)
   with BSMTP id 1025; Fri, 18 Dec 92 19:58:35 EST
Received: from TNTECH.BITNET by TNTECH.BITNET (PMDF #2902 ) id
 <01GSGZN8117AD08LDS@TNTECH.BITNET>; Fri, 18 Dec 1992 18:59:07 CST
X-Envelope-to: moo-cows@parc.xerox.com
X-VMS-To: IN%"moo-cows@parc.xerox.com"
MIME-version: 1.0
X-NS-Transport-ID: 08002008D0FD0032CEBA
Message-ID: <01GSGZN8117CD08LDS@TNTECH.BITNET>
Date:	Fri, 18 Dec 1992 16:59:07 -0800
From:	"Jon Brazelton, Residence Hall Coordinator" <JPB7946%TNTECH.bitnet@cunyvm.cuny.edu>
Sender: parc.xerox.com.PARC@xerox.com
To:	moo-cows@parc.xerox.com
Subject: Info on other MOOs
Content-transfer-encoding: 7BIT

Two previous messages made reference to MediaMOO and PlayhouseMOO.  As a
relative new-comer to the world of MOO, I was under the silly misunderstand
that LambdaMOO was the only MOO (as opposed to MUDs).  Could someone provide
a list of public MOOs, along with their internet address?

If I wanen't hooked before, this could definately put me over the edge!

---------------------------------------------------------------------------
                           Jon Brazelton / N4VRN
Residence Hall Coordinator               First Lieutenant (P), Signal Corps
Tennessee Technological University       278th Armored Cavalry Regiment
Cookeville, Tennessee                    Tennessee Army National Guard
                          JPB7946 @ TNTECH.edu
---------------------------------------------------------------------------

From cs.stanford.edu!crew Fri Dec 18 15:08:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Fri" "18" "December" "1992" "15:08:25" "-0800" "Roger Crew" "crew@cs.stanford.edu" "<9212182308.AA14212@Xenon.Stanford.EDU>" "113" "Re: Request for power testers " "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Fri, 18 Dec 1992 15:08:51 -0800
Received: from Xenon.Stanford.EDU ([36.28.0.25]) by alpha.xerox.com with SMTP id <12565>; Fri, 18 Dec 1992 15:08:22 PST
Received: from LOCALHOST by Xenon.Stanford.EDU with SMTP (5.61+IDA/25-CS-eef) id AA14212; Fri, 18 Dec 92 15:08:25 -0800
Message-Id: <9212182308.AA14212@Xenon.Stanford.EDU>
In-Reply-To: Your message of "Thu, 17 Dec 92 14:47:04 PST."
             <92Dec17.144709pst.58372@mu.parc.xerox.com> 
Date:	Fri, 18 Dec 1992 15:08:25 -0800
From:	Roger Crew <crew@cs.stanford.edu>
To:	Pavel Curtis <Pavel@parc.xerox.com>
Cc:	moo-cows@parc.xerox.com
Subject: Re: Request for power testers 

Looking over the new code, if I'm reading things right, it appears that

TRY
  <try-body>
FINALLY
  <finally-portion>
ENDTRY

is a form of unwind-protect, i.e., the finally-portion of the body
always gets executed no matter what errors occur in the main try-body,
unless something does a kill_task() or we run out of ticks.

It looks to me like it would be fairly straightforward to subtract n
ticks from the clock on entering the try-body (in EOP_TRY_FINALLY).
At the end of the try-body (EOP_END_TRY_FINALLY) or any unwinding of
the stack one would then restore those n ticks.  Then the
finally-portion would be guaranteed at least n ticks to run even if
the try-body runs out of ticks.  The idea here is that if there are
fewer than n ticks left when you get to the beginning of the TRY, then
you abort immediately with "out of ticks" (thus penalizing you for
beeing greedy --- one only reserves what one thinks one will need).

The handler entry on the stack would have to include a
number-of-ticks-to-restore field and you'd also be keeping track of
the total number of reserved ticks in any given task so that if the
task suspends, the reserved ticks can be subtracted from the 15000 (?)
that the newly-resumed task would ordinarily get when it resumes.
This way

(*) a background task would never be running with a tick allowance
   higher than 15000.

(*) once you reserve n ticks, those ticks stay reserved whether or not
   the task later suspends --- the ticks only go back when the handler
   gets popped off the stack (i.e., on a normal exit for the try body,
   or an exception that reaches that handler)

n could just be a constant (e.g., 500), or you could modify the syntax 
slightly:

TRY
  ...
FINALLY (300)
  (i.e, we'll say this section needs no more than 300 ticks to run)
  ...
ENDTRY


Another thought would be that the usual kill_task() be reinterpreted:

   Set ticks_left to 0 so that the next time the task attempts
   to run it dies.  Also set a flag to indicate that this really was a
   kill_task and not an ordinary out-of-ticks, so that we don't get a 
   backtrace.

The difference from before is that any pending finally sections will run 
(with only the allotment of ticks they had reserved on try-entry) to do
any cleanups that might be necessary.  

This would mostly fix the current problem in which any player's code 
I call can screw me by doing one of the following:

   1) divide_by_zero or some other random error 
         catchable by TRY...EXCEPT/FINALLY
   2) exhausting the tick/second clock
         would be catchable if TRY...FINALLY can reserve ticks
   3) issuing a kill_task(task_id())
         catchable if TRY...FINALLY can reserve ticks and
         kill_task() is simply a ticks_left := 0 operation;
   4) suspend() 
         (needs more thought ... see below)

We might conceivably still need a terminate-with-extreme-prejuidice function
for use by wizards.

vaporize_task() 
   set the tick clock to some suitably negative-infinite number. 
   Task dies immediately and no finally-sections get to run.
   (granted, this could be implemented the way kill-task currently is, since
   the effect is the same).


About catching suspends:

Given the above, one could try to fake this with
  TRY ... FINALLY (15000) ... ENDTRY 
since any suspend would result in an out-of-ticks that would
then unwind back to this finally section.  Admittedly, what
you really want is a way to get the finally clause to execute 
*before* the suspension takes place.  e.g.,
 TRY ... ONSUSPEND ... ENDTRY

An alternative would be a construct making suspend() a no-op for 
the duration of a particular statement or expression.

A third alternative would be a construct allowing one to specify
suspend hooks and resume hooks, e.g.,

CRITICAL
  <statements>
ONSUSPEND
  <prepare-for-hibernation code...>
ONRESUME
  <look-at-new-state-of-the-world code...>
ENDCRITICAL

it's rather annoying that statements and expressions are different
things, since we'd really need one of these constructs for each.

--
Roger Crew
Internet:   crew@CS.Stanford.EDU
LambdaMOO:  Rog

From parc.xerox.com!pavel Fri Dec 18 17:13:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "18" "December" "1992" "17:07:33" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "4" "Re: Request for power testers" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43023>; Fri, 18 Dec 1992 17:13:31 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12599>; Fri, 18 Dec 1992 17:12:07 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12591>; Fri, 18 Dec 1992 17:10:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Fri, 18 Dec 1992 17:07:51 -0800
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12587>; Fri, 18 Dec 1992 17:07:37 PST
Received: by mu.parc.xerox.com id <58374>; Fri, 18 Dec 1992 17:07:35 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0032CEDE
In-Reply-to: <9212182308.AA14212@Xenon.Stanford.EDU>
Message-ID: <92Dec18.170735pst.58374@mu.parc.xerox.com>
References: <9212182308.AA14212@Xenon.Stanford.EDU>
	<92Dec17.144709pst.58372@mu.parc.xerox.com>
Date:	Fri, 18 Dec 1992 17:07:33 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	moo-cows@parc.xerox.com
Subject: Re: Request for power testers

For most of you, Roger's message must not make any sense; it was sent in
response to a message I sent to him with much smaller distribution.

	Pavel

From wg7j.ece.orst.edu!g6phf Tue Dec 22 05:12:00 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "21" "December" "1992" "21:51:23" "-0800" "g6phf@wg7j.ece.orst.edu" "g6phf@wg7j.ece.orst.edu" nil "3" "NPC robot etc..." "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43017>; Tue, 22 Dec 1992 05:11:50 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11693>; Tue, 22 Dec 1992 05:11:06 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11691>; Tue, 22 Dec 1992 05:07:43 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Tue, 22 Dec 1992 04:59:21 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11691>; Tue, 22 Dec 1992 04:59:05 PST
Received: from wg7j.ECE.ORST.EDU ([128.193.48.123]) by alpha.xerox.com with SMTP id <11698>; Tue, 22 Dec 1992 04:56:50 PST
X-NS-Transport-ID: 08002008D0FD0032EF9E
Message-ID: <2868@wg7j.ECE.ORST.EDU>
Date:	Mon, 21 Dec 1992 21:51:23 -0800
From:	g6phf@wg7j.ece.orst.edu
To:	moo-cows.PARC@xerox.com
Subject: NPC robot etc...

 Hi, is it possible someone could point me to some source for a robot character, or even better mail me a sample. I would like 
to get things going on my moo
at home. Thanks!

From eowyn.radonc.washington.edu!weber Tue Dec 22 12:00:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "22" "December" "1992" "11:44:56" "-0800" "Eric Weber" "weber@eowyn.radonc.washington.edu " nil "9" "mail system" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43017>; Tue, 22 Dec 1992 12:00:14 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11748>; Tue, 22 Dec 1992 11:58:10 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11749>; Tue, 22 Dec 1992 11:53:54 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Tue, 22 Dec 1992 11:49:21 -0800
Received: from mailhost1.cac.washington.edu ([140.142.32.2]) by alpha.xerox.com with SMTP id <11741>; Tue, 22 Dec 1992 11:49:03 PST
Received: from eowyn.radonc.washington.edu by mailhost1.cac.washington.edu
	(5.65/UW-NDC Revision: 2.27 ) id AA21302; Tue, 22 Dec 92 11:50:41 -0800
Received: by eowyn.radonc.washington.edu.eowyn (4.1/SMI-4.1)
	id AA04022; Tue, 22 Dec 92 11:44:56 PST
X-NS-Transport-ID: 08002008D0FD0032F635
Message-ID: <9212221944.AA04022@eowyn.radonc.washington.edu.eowyn>
Date:	Tue, 22 Dec 1992 11:44:56 -0800
From:	weber@eowyn.radonc.washington.edu (Eric Weber)
To:	moo-cows@parc.xerox.com
Subject: mail system


Has anyone successfully written a mail system compatible with the
Lambda mail system in which the verbs normally defined on $player are
defined on a room instead?  I am in the process of creating such a
beast, but have gotten bogged down, so if I'm repeating someone else's
effort I'd appreciate hearing what you did.

-- Eric Weber
   a.k.a Tesseract@LambdaMOO

From camp.onet.edu!seth Wed Dec 23 12:44:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "23" "December" "1992" "07:59:31" "-0800" "Seth I. Rich" "seth%CAMP@onet.edu " nil "18" "Re: mail system" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43018>; Wed, 23 Dec 1992 12:44:26 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11825>; Wed, 23 Dec 1992 12:43:26 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11809>; Wed, 23 Dec 1992 12:38:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Wed, 23 Dec 1992 08:01:13 -0800
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11849>; Wed, 23 Dec 1992 08:00:43 PST
Received: from CAMP.Onet.Edu ([141.110.32.5])  for seth@CAMP.Onet.Edu
	by oscsunb.osc.edu (5.65c+KVa/921206.2314) id AA09648; Wed, 23 Dec 1992 11:00:22 -0500
Received: from bell.glmtctpm by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA14843; Wed, 23 Dec 92 10:59:31 EST
X-NS-Transport-ID: 08002008D0FD0033053C
Message-ID: <9212231559.AA14843@CAMP.Onet.Edu>
Date:	Wed, 23 Dec 1992 07:59:31 -0800
From:	seth%CAMP@onet.edu (Seth I. Rich)
Sender: seth@camp.onet.edu
To:	weber@eowyn.radonc.washington.edu, MOO-Cows@parc.xerox.com
Subject: Re: mail system

Eric Weber (Tesseract@LambdaMOO) wrote:

> Has anyone successfully written a mail system compatible with the
> Lambda mail system in which the verbs normally defined on $player are
> defined on a room instead?  I am in the process of creating such a
> beast, but have gotten bogged down, so if I'm repeating someone else's
> effort I'd appreciate hearing what you did.

I'm very close to this, but not quite there yet... In work I'm doing on
OpalMOO, I'm trying to modify the mail system to make it more VR, requiring
one to go to the Post Office in order to get one's mail (which will be 
objects, in the final incarnation of the beast), allowing one to subscribe
for home delivery, and so forth.

While I'm not -done- with this project yet, I've come a long way with it;
I'd be more than willing to help if there's anything I can help with.

Seth / Blackbriar @ LambdaMOO / OpalMOO

From camp.onet.edu!seth Wed Dec 23 12:44:32 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "23" "December" "1992" "07:59:31" "-0800" "Seth I. Rich" "seth%CAMP@onet.edu " nil "18" "Re: mail system" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43018>; Wed, 23 Dec 1992 12:44:26 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11825>; Wed, 23 Dec 1992 12:43:26 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11809>; Wed, 23 Dec 1992 12:38:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Wed, 23 Dec 1992 08:01:13 -0800
Received: from oscsunb.osc.edu ([128.146.36.2]) by alpha.xerox.com with SMTP id <11849>; Wed, 23 Dec 1992 08:00:43 PST
Received: from CAMP.Onet.Edu ([141.110.32.5])  for seth@CAMP.Onet.Edu
	by oscsunb.osc.edu (5.65c+KVa/921206.2314) id AA09648; Wed, 23 Dec 1992 11:00:22 -0500
Received: from bell.glmtctpm by  CAMP.Onet.Edu (4.1/SMI-4.1)
	id AA14843; Wed, 23 Dec 92 10:59:31 EST
X-NS-Transport-ID: 08002008D0FD0033053C
Message-ID: <9212231559.AA14843@CAMP.Onet.Edu>
Date:	Wed, 23 Dec 1992 07:59:31 -0800
From:	seth%CAMP@onet.edu (Seth I. Rich)
Sender: seth@camp.onet.edu
To:	weber@eowyn.radonc.washington.edu, MOO-Cows@parc.xerox.com
Subject: Re: mail system

Eric Weber (Tesseract@LambdaMOO) wrote:

> Has anyone successfully written a mail system compatible with the
> Lambda mail system in which the verbs normally defined on $player are
> defined on a room instead?  I am in the process of creating such a
> beast, but have gotten bogged down, so if I'm repeating someone else's
> effort I'd appreciate hearing what you did.

I'm very close to this, but not quite there yet... In work I'm doing on
OpalMOO, I'm trying to modify the mail system to make it more VR, requiring
one to go to the Post Office in order to get one's mail (which will be 
objects, in the final incarnation of the beast), allowing one to subscribe
for home delivery, and so forth.

While I'm not -done- with this project yet, I've come a long way with it;
I'd be more than willing to help if there's anything I can help with.

Seth / Blackbriar @ LambdaMOO / OpalMOO

From uqeve.cc.uq.oz.au!DPMT Wed Dec 23 14:16:28 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "23" "December" "1992" "14:05:33" "-0800" "Matthew S Trevor" "DPMT@uqeve.cc.uq.oz.au" nil "6" "Merry Christmas to All" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43018>; Wed, 23 Dec 1992 14:16:18 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11834>; Wed, 23 Dec 1992 14:14:44 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11831>; Wed, 23 Dec 1992 14:12:05 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58375>; Wed, 23 Dec 1992 14:07:20 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11826>; Wed, 23 Dec 1992 14:06:42 PST
Received: from bunyip.cc.uq.oz.au ([130.102.2.1]) by alpha.xerox.com with SMTP id <11831>; Wed, 23 Dec 1992 14:05:56 PST
Received: from uqvax.cc.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP);
          Thu, 24 Dec 1992 08:05:33 +1000
Received: from decnet-daemon (DPMT@UQEVE) by uqvax.cc.uq.oz.au (PMDF #2422 ) 
          id <01GSOQLYGJ8W8WWY3P@uqvax.cc.uq.oz.au>;
          Thu, 24 Dec 1992 08:05:33 AEST
X-Envelope-to: Moo-cows.parc@xerox.com
X-VMS-To: UQVAX::IN%"Moo-cows.parc@xerox.com"
MIME-version: 1.0
X-NS-Transport-ID: 08002008D0FD00330619
Message-ID: <01GSOQLYGJ8Y8WWY3P@uqvax.cc.uq.oz.au>
Date:	Wed, 23 Dec 1992 14:05:33 -0800
From:	Matthew S Trevor <DPMT@uqeve.cc.uq.oz.au>
To:	Moo-cows.parc@xerox.com
Subject: Merry Christmas to All
Content-transfer-encoding: 7BIT


At the risk of offending everyone, I'd just like to say Merry Christmas to 
all the Moo-ites.  I hope to have more luck in seeing you all again next 
year.

Morpheus

From ee.ualberta.ca!daum Mon Dec 28 11:11:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "28" "December" "1992" "10:57:08" "-0800" "Comrade Porcupine" "daum@ee.ualberta.ca" nil "12" "Requests for next server" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Mon, 28 Dec 1992 11:11:48 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11593>; Mon, 28 Dec 1992 11:11:20 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11574>; Mon, 28 Dec 1992 11:06:40 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58374>; Mon, 28 Dec 1992 10:59:04 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11574>; Mon, 28 Dec 1992 10:58:35 PST
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11574>; Mon, 28 Dec 1992 10:57:43 PST
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA15573; Mon, 28 Dec 92 11:57:10 -0700
Full-Name: Comrade Porcupine
Mailer: Elm [revision: 66.25]
X-NS-Transport-ID: 08002008D0FD00331B5B
Message-ID: <92Dec28.105743pst.11574@alpha.xerox.com>
Date:	Mon, 28 Dec 1992 10:57:08 -0800
From:	Comrade Porcupine <daum@ee.ualberta.ca>
To:	moo-cows.PARC@xerox.com
Subject: Requests for next server

I really think the next server release should have teh following additions:

addition of a read_text_file() command with similar restrictions to
open_network_connection()

a complete re-haul of o_n_c ... there are major problems with its current
incarnation ...

(such as having to login an outgoing o_n_c, the 5 minute timeout not
completely removing the connection, which slows down the server
dramatically, etc)


From parc.xerox.com!pavel Mon Dec 28 18:46:02 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "28" "December" "1992" "18:36:17" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "10" "Re: Requests for next server" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43014>; Mon, 28 Dec 1992 18:45:50 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11624>; Mon, 28 Dec 1992 18:44:11 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11623>; Mon, 28 Dec 1992 18:41:43 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58375>; Mon, 28 Dec 1992 18:37:32 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11620>; Mon, 28 Dec 1992 18:37:11 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11623>; Mon, 28 Dec 1992 18:36:41 PST
Received: by mu.parc.xerox.com id <58375>; Mon, 28 Dec 1992 18:36:31 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00331FAF
In-Reply-to: <92Dec28.105743pst.11574@alpha.xerox.com>
Message-ID: <92Dec28.183631pst.58375@mu.parc.xerox.com>
References: <92Dec28.105743pst.11574@alpha.xerox.com>
Date:	Mon, 28 Dec 1992 18:36:17 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	daum@ee.ualberta.ca
cc:	moo-cows.PARC@xerox.com
Subject: Re: Requests for next server

> Date:	Mon, 28 Dec 1992 10:57:08 -0800
> From:	Comrade Porcupine <daum@ee.ualberta.ca>
> 
> ... the 5 minute timeout not completely removing the connection, which slows
> down the server dramatically, etc)

I'm unaware of any problem fitting this description; could you please
elaborate?

	Pavel

From ee.ualberta.ca!daum Mon Dec 28 19:13:15 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "28" "December" "1992" "19:12:39" "-0800" "Comrade Porcupine" "daum@ee.ualberta.ca" nil "19" "Re: Requests for next server" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43014>; Mon, 28 Dec 1992 19:13:09 -0800
Received: from bode.ee.ualberta.ca ([129.128.16.96]) by alpha.xerox.com with SMTP id <11716>; Mon, 28 Dec 1992 19:12:52 PST
Received: by bode.ee.ualberta.ca
	(16.6/15.6) id AA19883; Mon, 28 Dec 92 20:12:40 -0700
Full-Name: Comrade Porcupine
In-Reply-To: <92Dec28.183631pst.58375@mu.parc.xerox.com>; from "Pavel Curtis" at Dec 28, 92 6:36 pm
Mailer: Elm [revision: 66.25]
Message-Id: <92Dec28.191252pst.11716@alpha.xerox.com>
Date:	Mon, 28 Dec 1992 19:12:39 -0800
From:	Comrade Porcupine <daum@ee.ualberta.ca>
To:	Pavel@parc.xerox.com (Pavel Curtis)
Subject: Re: Requests for next server

> 
> > Date:	Mon, 28 Dec 1992 10:57:08 -0800
> > From:	Comrade Porcupine <daum@ee.ualberta.ca>
> > 
> > ... the 5 minute timeout not completely removing the connection, which slows
> > down the server dramatically, etc)
> 
> I'm unaware of any problem fitting this description; could you please
> elaborate?
> 
> 	Pavel
> 

	Unsure if I can be definite about this, but I have noticed a drastic
slowdown which is reduced by doing something like:

	for x in [0..-200] boot_player(toobj(x)); endfor

	After doing that there is a dramatic speed increase...

From media.mit.edu!asb Wed Dec 30 12:06:59 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "30" "December" "1992" "11:53:35" "-0800" "asb@media.mit.edu" "asb@media.mit.edu" nil "21" "@foo me is <value>" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43014>; Wed, 30 Dec 1992 12:06:53 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11817>; Wed, 30 Dec 1992 12:06:16 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11816>; Wed, 30 Dec 1992 12:00:22 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58376>; Wed, 30 Dec 1992 11:54:13 -0800
Received: from media.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <11816>; Wed, 30 Dec 1992 11:53:43 PST
Received: by media.mit.edu (5.57/DA1.0.4.amt)
	id AA24123; Wed, 30 Dec 92 14:53:35 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD00333111
Message-ID: <9212301953.AA24123@media.mit.edu>
Date:	Wed, 30 Dec 1992 11:53:35 -0800
From:	asb@media.mit.edu
To:	moo-cows@parc.xerox.com
cc:	asb@media.mit.edu
Subject: @foo me is <value>


The message syntax is really handy.  

(You can just create a property named foo_msg, and then the server
automatically interprets "@foo <object> is <message>" to let you set the
foo_msg of anything you own.  Permissions are handled automatically.)


Here's my question:

Why not generalize this, and drop the need for adding "_msg" to the property
name?  (The slot would now be named "foo" instead of "foo_msg", and all slots
could be set in this fashion.)  This would be done last, so any existing @foo
verbs would take priority, if they exist.  The server would need to check the
type of the <value> and produce an appropriate error message.

What do people think?

-- Amy
	jaime@LambdaMOO
	asb@media-lab.media.mit.edu

From theory.cs.mankato.msus.edu!nop Thu Dec 31 00:21:58 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "31" "December" "1992" "00:11:49" "-0800" "Jay A. Carlson" "nop@theory.cs.mankato.msus.edu " nil "42" "o_n_c()" "^Date:" nil nil "12"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43015>; Thu, 31 Dec 1992 00:21:49 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11521>; Thu, 31 Dec 1992 00:19:10 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11527>; Thu, 31 Dec 1992 00:16:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58377>; Thu, 31 Dec 1992 00:11:57 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11523>; Thu, 31 Dec 1992 00:11:30 PST
Received: from theory.cs.mankato.msus.edu ([134.29.8.244]) by alpha.xerox.com with SMTP id <11521>; Thu, 31 Dec 1992 00:10:48 PST
Received: by theory.cs.mankato.msus.edu (5.65/DEC-Ultrix/4.3)
	id AA03222; Thu, 31 Dec 1992 02:11:49 -0600
X-NS-Transport-ID: 08002008D0FD003335EB
In-Reply-to: "Leonard N. Foner's message of Wed, 30 Dec 92 21:54:56 -0500 <9212310254.AA08502@media.mit.edu>"
Message-ID: <9212310811.AA03222@theory.cs.mankato.msus.edu>
Date:	Thu, 31 Dec 1992 00:11:49 -0800
From:	nop@theory.cs.mankato.msus.edu (Jay A. Carlson)
To:	moo-cows.PARC@xerox.com
cc:	foner@media.mit.edu, jonathan@nova.decio.nd.edu
Subject: o_n_c()

    Gee, that's interesting.  My reading of the documentation seemed to
    suggest that o_n_c() would expect the other end to log in as a
    character within five minutes or the connection would be closed, which
    never made much sense to me in terms of functionality.  I gather that
    this it not the case; correct?  I haven't been there yet to check out
    the code; can you suggest some good object ID's to look at?

This is almost true; the server will boot unlogged-in connections that
have been IDLE for five minutes.  Note that this length of time is
selectable in options.h, and the booting can be disabled completely.

Also, you can hack #0:do_login_command() to automatically log in
connections as fake players as soon as it notices them; this is what
$network:open() does on JH, and the OrbitNet links use this.  The only
bad thing about this is that the server will send `*** Connected ***'
to the connection.  For things like OrbitNet this is OK but for, say,
finger, this is a killer.  Fortunately, finger can be done nicely with
unlogged-in connections, since it (hopefully) won't be idle for over
five minutes....

If you're interested in this, log into JaysHouse, @chparent me to
$prog, and peer at #0:stuff, $network, $gopher, #370 and #379,
although I have to admit I don't know much about #379, the batch
network query services room, or $gopher.

I'm very interested in seeing what network services can be mapped onto
a MUD nicely; one thing I'm thinking about now is hooking up with our
online card catalog, to create a library people can browse. 

Looking for a book?  Wave your magic wand and make the library be
sorted by subject.  Or maybe it would be more convenient right now to
have this particular shelf sorted by author.  Grab the book off the
shelf and carry it down to the circulation desk and check it out
(reserve it) with your library card (which has your ID on it).

I'm currently writing a minipaper on direct MOO to MOO networking and
the design of OrbitNet, so this is kinda on the back burner for now,
but this is something I'd actually use, so.

Jay Carlson
nop@theory.cs.mankato.msus.edu
JaysHouseMOO is at theory.cs.mankato.msus.edu port 1709.

