From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6807>; Fri, 11 Jan 1991 20:35:08 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <18146>; Fri, 11 Jan 1991 20:34:43 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <18146>; Fri, 11 Jan 1991 20:33:41 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA00116; Sat, 12 Jan 91 15:28:54 EST
Posted-Date: Sat, 12 Jan 91 15:30:16 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Sat, 12 Jan 91 15:30:16 EST
X-To: MC
X-Cc: Multi-Player Projects and Permissions
X-NS-Transport-ID: 08002008D0FD00060F4F
Message-ID: <9101120428.AA00116@anu.anu.edu.au>
Date:	Sat, 12 Jan 1991 12:30:16 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: What follows is Gary_Severn's ideas on modifications to the MOO server to allow

several players to cooperate in a programming and/or building project. The
other major participant was EbbTide, who will hopefully make his own entry.
Thanks to Gemba for some proof-reading and suggestions.

The method I have in mind uses the concept of a realm, which is a collection of
objects, verbs and properties with the same permissions. Realm does not replace
owner, this system needs both of them to be robust. By default, realm would be
equal to owner. The basic idea is that owner defines responsibility, and realm
defines who the object/verb/property (OPV) trusts. So being in a realm conveys
no special rights upon an OPV.

One can also imagine a system that replaces owner with realm, so that two
verbs, say, that a player owned might not be allowed to call each other. I
think such a system would probably be fairly similar to this one, but slightly
simpler. Also, perhaps we should be thinking about hierarchies of realms,
perhaps a realm inherits all the players in its parent's lists.

I divide permissions into five levels. Usually, anyone allowed to do a level n
action will be allowed to do a level n+1 action.

  1. -- Program a verb. Note this is an awfully powerful ability, since the
	verb is going to have all the privileges of its owner.

  2. -- Write to a property.
     -- Recycle objects, remove properties and verbs.
     -- Move an object, property or verb's realm from a given realm. 
     -- Change an object, property or verb's owner to oneself. (No-one else)
     -- Execute a protected verb. Note this concept doesn't exits yet in Lambda
	MOO, but I think it should. It's what I thought the x flag was going to
	be when I first heard about it, not that the x flag isn't an elegant
	construct in its own right. A protected verb under the current system
	would be one called only by other verbs of the same owner. I think this
	is worth doing regardless of what we decide about inter-player
	cooperation.

  3. -- Place an OPV in a realm (i.e you need less privilege in the realm
	you are moving it to than the one you are moving it from.)
     -- Create a property or verb on an object in a realm.

  4. -- Read a property, list a verb, find out what properties and verbs there
	are on an object.

  5. -- Read the properties that are usually called globally readable anyway.
	e.g. name, aliases.

Basically, 5. would normally be available to everyone, since most of the
built-in programs would crash if it weren't so. A player with level 4
authorisation in a realm can probably read enough info to spoil a lot of
puzzles, etc, but can't do any damage. With level 3, one can create some
irritating pollution, but not destroy anything. With level 2, you can reprogram
objects, etc and build and destroy with gay abandon, but if you program the
verb ends up belonging to you at the end. With level 1, the realm system
becomes a trojan horse. If you own a single verb in a realm I have level 1
authority in, I can destroy everything you own on the MOO.

I do hope no-one will point out methods of doing these things I describe with
lower levels of authorisation. :) Level 1 is just too obscene to allow in a
software system, so I'd advise excluding it. Level 5 could be fairly safely
allowed to operate as it does, although if you don't want people @realm ing
your possessions this is how you stop them. So the real meat of the system is
in levels 2 through 4.

Now the realm property on an OPV is going to be either:

  -- A player object, normally the OPV's owner.
  -- A realm object
  -- A list of the above.

Realm objects would normally be children of (you guessed it) the generic realm.
The generic realm has a list of authorised players on it for each of levels 2 3
and 4, and, just to give a little more flexibility, verbs that use them. Ouch,
this could get recursive. Well, the verbs _must_ be globally executable, that's
all the server checks. The server, of course, has to call the realm permission
system whenever things I mentioned in the list above happen. I suspect Lambda
will regard having to call verbs as rather dangerous though, so perhaps we will
have to settle for looking at properties. In that case, it will probably end up
looking like locking, with locked_to and locked_against lists. The probem is to
duplicate the most common verb forms in properties, which is the same problem
as locking, so one would expect a similar solution. Perhaps.

There would be some public realms that defined the most common defaults, known
as globally_readable, globally_writable, and mine_mine_all_mine_keep_your_
grubby_paws_off_it. Actually, that last doesn't really need to be a realm at
all, as I've described it, but perhaps having it is easier than permitting
realms to be players.

The obvious next question is, who defines who has authority in a realm? The
answer is, whoever is authorised to do so in the realm which that realm
property is a member of. I think by default only the owner of the realm object
should be able to, but authorising the members of the "second circle" (level 2)
would also be reasonable (a collegiate system).

I hope these comments are useful, since permissions and security is a field
where one minor error can make all the rest nonsense. Anyway, if I have got
this right then implementation would seem fairly straightforward. The next hard
question, which I don't feel qualified to answer, is how much overhead this is
going to cost, i.e. how complex and how MOO-based does a solution need to be
before Lambda will spit it out?
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn et al
------------------------------------------------------------------------------
"Are you listening Bog? Is a computer one of your creatures?" -R.A. Heinlein

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <hpb.cis.pitt.edu!hobbes>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6807>; Fri, 11 Jan 1991 21:31:18 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <18146>; Fri, 11 Jan 1991 21:30:47 PST
Received: from hpb.cis.pitt.edu ([130.49.6.51]) by alpha.xerox.com with SMTP id <18146>; Fri, 11 Jan 1991 21:28:55 PST
Received: by hpb.cis.pitt.edu (5.57/Ultrix2.4-C)
	id AA11002; Sat, 12 Jan 91 00:26:07 EST
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD00060F95
In-Reply-to: "<9101120428.AA00116@anu.anu.edu.au>; from \"David Bofinger\" at Jan 12, 91 12:30 pm"
Message-ID: <9101120526.AA11002@hpb.cis.pitt.edu>
Date:	Fri, 11 Jan 1991 21:26:06 PST
From:	hobbes@hpb.cis.pitt.edu (The Rain In Spain Falls Mainly On The Plane)
To:	DXB105@phys.anu.edu.au (David Bofinger)
cc:	MOO-Cows.parc@xerox.com
Subject: Re: What follows is Gary_Severn's ideas on modifications to the MOO server to allow

-> The method I have in mind uses the concept of a realm, 
-> ... So being in a realm conveys
-> no special rights upon an OPV.

Okay..Realms as first defined for the MUD generation by Tygryss:
  A set of rooms that follow specific rules.  A subsection of the Uber (which
was what this realm stuff was done for first) which has its own universe
rules, different than the rest of the MUD..

Note that this is NOT the definition given by Gary_Severn...I happen to think
that BOTH can be done in MOO, however Tygryss' def is MUCH easier..:->

AND! depending on what is in the realm, I think that being in a realm is,
perhaps, very dangerous, if the person involved is, shall we say, less than
honorable...

->I divide permissions into five levels. 
-> 
->   1. -- Program a verb. Note this is an awfully powerful ability, since the
-> 	verb is going to have all the privileges of its owner.

Well, I scanned through the stuff ahead and behind, and have promptly decided
to say 'yah, I think this sounds good, but see later..'

-> 
->   2. -- Write to a property.
ok.
->      -- Recycle objects, remove properties and verbs.
ok, this seems as good as moving an object out of the realm.
->      -- Move an object, property or verb's realm from a given realm. 
ok.
->      -- Change an object, property or verb's owner to oneself. (No-one else)
I dunno...but I guess if you get Level 2 in a realm, you must be well trusted
or have started the realm yourself, and prolly have Level 1 status..
->      -- Execute a protected verb.
ok..I like level 2..my complaints begin with level 3...
-> 
->   3. -- Place an OPV in a realm (i.e you need less privilege in the realm
-> 	you are moving it to than the one you are moving it from.)
->      -- Create a property or verb on an object in a realm.
what's to stop me from creating foo, then creating foo:bar, then dumping both
into the realm? which seems to me to be level 1 permissions?
-> 
->   4. -- Read a property, list a verb, find out what properties and verbs there
-> 	are on an object.
good.
-> 
->   5. -- Read the properties that are usually called globally readable anyway.
-> 	e.g. name, aliases.
I would hope this is default for everything, yes.
-> 
-> I do hope no-one will point out methods of doing these things I describe with
-> lower levels of authorisation. :) 

oops..sorry..:->..of course, I may be wrong..

-> 
-> Now the realm property on an OPV is going to be either:
-> 
->   -- A player object, normally the OPV's owner.
->   -- A realm object
->   -- A list of the above.
-> 
Why not just keep it as a list in all cases? it'll be easier, because you won't
have to check for one or the other, just go thru the list...it kinda smax of
recursion, but ...
Gary mentions a problem with Locking..I haven't seen this problem, coming into 
the MOO scene as late as I did, so I don't know what the problem or the
solution is (are? I hate the english language)
-> 
-> There would be some public realms that defined the most common defaults, known
-> as globally_readable, globally_writable, and mine_mine_all_mine_keep_your_
-> grubby_paws_off_it. 
I see the last one as '@realm OPV is {player}' which I don't think Gary likes..
I can see the problems with that, however, if only a person in the realm is
allowed write permission on an object, and the only person in the realm is
player, then only player can do stuff to the OPV, right?
Also: what about globally_do_everything_to..this is G_Readable, and G_writable
...G_writable may include G_Readable, but not necessarily..

-> 
-> The obvious next question is, who defines who has authority in a realm? The
-> answer is, whoever is authorised to do so in the realm which that realm
-> property is a member of. I think by default only the owner of the realm object
-> should be able to, but authorising the members of the "second circle" (level 2)
-> would also be reasonable (a collegiate system).
The next question to be asked is 'who owns the realm object?'..when Gary and I 
were talking about this, he mentioned having the realm object own itself, with
write permissions being given to realmobject.writelist (i.e. those people in
the realm with write permission)...I don't recall the levels being mentioned,
but I like them better.

-> question, which I don't feel qualified to answer, is how much overhead this is
-> going to cost, i.e. how complex and how MOO-based does a solution need to be
-> before Lambda will spit it out?
-> 		MOO:	Gary_Severn et al

Well, overhead is something that is very important..if I recall correctly, 
Uber didn't drag the server much at all..until you started running functions
alot..for example, my UberBed, which had about 8 functions (lie, stand, pillow,
snuggle, push, pull, plv) (ok, 7 functions) grabbed the server pretty hard
when 7 people were actively trying to do each other in..this was on a DS3100
with small disk and small mem..(valkyrie.ecn.uoknor.edu, if you know Random)
I have a feeling that this will happen to MOO also..in a semi popular MUD,
say, PoohMUD, if you remember that golden hack, implemented in MOO, would 
prolly grab the server kinda hard, in any case..this might add a few 
milliseconds of delay when used.  I don't think this would be used much..
I'm not saying this is not a useful change, quite the opposite, I think it
is a step towards better building and programming because of communication,
however, once the MUD is built and running smoothly, I don't think this
function/feature/whatever you want to call it will be used OFTEN..(i.e.
once people get over the 'gee, I like this new mud, let's build' stage,
it will get less usage)...

Whatever, I've blathered on enuf about it..cya..EbbTide


-- 
hobbes@hpb.cis.pitt.edu     | "My moral standing is lying down" - NIN
wbfst1@unix.cis.pitt.edu    | "I used to think that love was sensible" - IS
Tigger@zets (where's that?) | "What you say should be from your own mind!" - NE

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <hpb.cis.pitt.edu!hobbes>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7112>; Sun, 13 Jan 1991 16:27:17 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <18242>; Sun, 13 Jan 1991 16:27:01 PST
Received: from hpb.cis.pitt.edu ([130.49.6.51]) by alpha.xerox.com with SMTP id <18242>; Sun, 13 Jan 1991 16:26:28 PST
Received: by hpb.cis.pitt.edu (5.57/Ultrix2.4-C)
	id AA12498; Sun, 13 Jan 91 19:25:11 EST
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD000616E4
In-Reply-to: "<9101140003.AA05117@anu.anu.edu.au>; from \"David Bofinger\" at Jan 14, 91 8:03 amtem: M"
Message-ID: <9101140025.AA12498@hpb.cis.pitt.edu>
Date:	Sun, 13 Jan 1991 16:25:09 PST
From:	hobbes@hpb.cis.pitt.edu (The Rain In Spain Falls Mainly On The Plane)
To:	DXB105@phys.anu.edu.au (David Bofinger)
cc:	MOO-Cows.parc@xerox.com
Subject: re: realms stuff..

Ok, I figgered for this reply not to quote, coz there was too much stuff there
for me to say "I agree" to..

as for ownership of realm objects, from gary's list of things, I'd say
just the M/A method..that is only one person is allowed to enter things
in a realm...anyone above level (x) can take them out.

-- 
hobbes@hpb.cis.pitt.edu     | "My moral standing is lying down" - NIN
wbfst1@unix.cis.pitt.edu    | "I used to think that love was sensible" - IS
Tigger@zets (where's that?) | "What you say should be from your own mind!" - NE

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7143>; Sun, 13 Jan 1991 23:55:31 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <18253>; Sun, 13 Jan 1991 23:55:07 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <18253>; Sun, 13 Jan 1991 23:53:43 PST
Received: by watcgl.waterloo.edu
	id <AA25502>; Mon, 14 Jan 91 02:53:01 EST
X-NS-Transport-ID: 08002008D0FD00061813
Message-ID: <9101140753.AA25502@watcgl.waterloo.edu>
Date:	Sun, 13 Jan 1991 23:53:01 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	DXB105@phys.anu.edu.au, MOO-Cows.parc@xerox.com
Subject: g7's moo perms proposal

eek!  i'm not too fond of the current permissions systems, but multi-
level'ing it doesn't seem to be the way to go, imo.

if you really want group building, use a common building account, or
re-implement unix groups, if ya have to.

my preference would be to rip out the current perms system, and force
all property/verb/object access to be done by a verb call, which checks
permissions.  yeah, this'd be real slow, but it's more object-oriented,
y'know?

anyway, that's the way i was gonna do it for 2.0 cept i realized it would
be way slow and anyway, who needs complex perms?  moveto/accept functions
are only ever used to emulate JUMP_OK it seems, anyway.

well, that's my $.02.

-- ghond





From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7144>; Sun, 13 Jan 1991 23:56:03 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <18251>; Sun, 13 Jan 1991 23:55:45 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <18251>; Sun, 13 Jan 1991 23:54:18 PST
Received: by watcgl.waterloo.edu
	id <AA25513>; Mon, 14 Jan 91 02:54:01 EST
X-NS-Transport-ID: 08002008D0FD00061815
Message-ID: <9101140754.AA25513@watcgl.waterloo.edu>
Date:	Sun, 13 Jan 1991 23:54:01 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	DXB105@phys.anu.edu.au, hobbes@hpb.cis.pitt.edu
cc:	MOO-Cows.parc@xerox.com
Subject: Re: What follows is Gary_Severn's ideas on modifications to the MOO server to allow

realms were necessary on uber to cover the fact that it had no
inheritance.

-- ghond

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7111>; Sun, 13 Jan 1991 16:15:02 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <18243>; Sun, 13 Jan 1991 16:14:51 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <18242>; Sun, 13 Jan 1991 16:13:48 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA05134; Mon, 14 Jan 91 11:07:39 EST
Posted-Date: Mon, 14 Jan 91 11:10:32 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Mon, 14 Jan 91 11:10:32 EST
X-To: MC
X-Cc: Spoofing in MOO-Cows.
X-NS-Transport-ID: 08002008D0FD000616DD
Message-ID: <9101140007.AA05134@anu.anu.edu.au>
Date:	Mon, 14 Jan 1991 08:10:32 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: OK, so I spoofed EbbTide in my last posting. Actually, -> is me, and > is

EbbTide, not the other way around as I stated. Thanks, Gemba.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"When a scientific genius becomes involved in the mystical mumbo-jumbo, the
    result is likely to be a lunatic whose quest for eternal life massacres
    everything in sight, but such poor souls wouldn't willingly harm a fly"
					-- Barry Hughart, `Bridge of Birds'

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7110>; Sun, 13 Jan 1991 16:08:15 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <18242>; Sun, 13 Jan 1991 16:07:51 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <18242>; Sun, 13 Jan 1991 16:06:47 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA05117; Mon, 14 Jan 91 11:03:23 EST
Posted-Date: Mon, 14 Jan 91 11:03:26 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Mon, 14 Jan 91 11:03:26 EST
X-To: MC
X-NS-Transport-ID: 08002008D0FD000616D4
Message-ID: <9101140003.AA05117@anu.anu.edu.au>
Date:	Mon, 14 Jan 1991 08:03:26 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: I've been told that my first letter was far too long and complicated for such a

simple idea, so although I'm going to add to it, I'll try to keep it under
control. -> is EbbTide, > is me.

-> The method I have in mind uses the concept of a realm, 
-> ... So being in a realm conveys no special rights upon an OPV.

Rememeber that second line, it'll be important later. Being in a realm (under
the proposal outlined here) may expose you to other's predations, but it
doesn't let you do anything. .owner does that.

>Okay..Realms as first defined for the MUD generation by Tygryss:
>[definition deleted]

As I see it, this is what we implement as a branch of the parenting tree. It is
quite a different concept from what I am talking about. I wasn't aware realm
had been semi-officially used this way, I'm happy to accept an alternative
term. Sorry for the confusion.
 
>AND! depending on what is in the realm, I think that being in a realm is,
>perhaps, very dangerous,

'being in a realm'? You mean putting your character object in a realm? Ouch.
Yes, does sound dangerous. Don't do it.

>if the person involved is, shall we say, less than
>honorable...
 
Dangerous for dishonourable people? Doesn't sound too bad :). Seriously, yes,
any object in a realm is exposed to those who have privileges in that realm,
but that's the _point_ of it.

->      -- Change an object, property or verb's owner to oneself. (No-one else)
>I dunno...but I guess if you get Level 2 in a realm, you must be well trusted
>or have started the realm yourself, and prolly have Level 1 status..

No, lots of people may have level 2 without level 1, indeed, I currently
wouldn't advise implementing level 1 in realms (for reasons explained in my
last posting). This ability is what you need to use .program, but it doesn't
allow you to create trojan horses, at least not usually.

->      -- Create a property or verb on an object in a realm.
>what's to stop me from creating foo, then creating foo:bar, then dumping both
>into the realm?

Nothing. That's what level 3 is for. It lets you build, but not demolish, so
you can give it to people you want to cooperate with but don't _really_ trust.

> which seems to me to be level 1 permissions?

Again, having an object in a realm conveys no special abilities. The process
you describe creates a verb that other people in the realm can run.

->   5. -- Read the properties that are usually called globally readable anyway.
-> 	e.g. name, aliases.
>I would hope this is default for everything, yes.

Making it not the default is an interesting idea, but an upward-compatibility
nightmare. Alas. The thought is there to provoke comment.

-> Now the realm property on an OPV is going to be either:
-> 
->   -- A player object, normally the OPV's owner.
->   -- A realm object
->   -- A list of the above.
-> 
>Why not just keep it as a list in all cases? it'll be easier, because you won't
>have to check for one or the other, just go thru the list...it kinda smax of
>recursion, but ...

Well, yes, that's what I meant, really. Sorry.

>Gary mentions a problem with Locking..I haven't seen this problem, coming into 
>the MOO scene as late as I did, so I don't know what the problem or the
>solution is (are? I hate the english language)

Not really a problem, just an analogy. In locking, an object must decide
whether it wants to let X fiddle with it. This is obviously a job for a verb,
but for convenience Lambda has included lists locked_to and locked_against, to
approximate the most common verbs' behaviours. Similarly, deciding who has
permissions in a realm is a job for a verb, but since Lambda is (I understand)
leery of massively infinite recursion problems (how unreasonable :) ) we have
to approximate it with lists. I suggest lists for levels 2, 3 and 4
authorisation. Look, if you don't agree with that philosophy forget I said it,
it's not important.

-> There would be some public realms that defined the most common defaults, known
-> as globally_readable, globally_writable, and mine_mine_all_mine_keep_your_
-> grubby_paws_off_it. 
>I see the last one as '@realm OPV is {player}' which I don't think Gary likes..

No, Gary likes this. actually, I thought Gary said it might work like that.

>I can see the problems with that, however, if only a person in the realm is
>allowed write permission on an object, and the only person in the realm is
>player, then only player can do stuff to the OPV, right?

Is this a problem? I thought this was the way it works now. Anything belonging
to player can do things, if that makes it clearer.

-> The obvious next question is, who defines who has authority in a realm? The
-> answer is, whoever is authorised to do so in the realm which that realm
-> property is a member of. I think by default only the owner of the realm object
-> should be able to, but authorising the members of the "second circle" (level 2)
-> would also be reasonable (a collegiate system).

>The next question to be asked is 'who owns the realm object?'..when Gary and I 
>were talking about this, he mentioned having the realm object own itself, with
>write permissions being given to realmobject.writelist (i.e. those people in
>the realm with write permission)...I don't recall the levels being mentioned,
>but I like them better.
 
As I see it:
  -- Master/Apprentice system: Master owns the realm properties & object.
Therefore, ony the master has the authority to admit apprentices.
  -- Collegiate System: realm properties and object are themselves members of
the realm. Hence, anybody with level 2 authority can admit apprentices.
  -- Hybrids. M/A for write lists, C for read lists, etc.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn et al
		MUSH:	Khamul, Number_Ten_Ox, Li_Kao, von_Neanderthal
------------------------------------------------------------------------------
"In the beginning there was the word, and the word was Aardvark." - Cerebrus

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6813>; Mon, 14 Jan 1991 11:27:15 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <18333>; Mon, 14 Jan 1991 10:32:29 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <18311>; Mon, 14 Jan 1991 10:21:27 PST
Received: by lambda.parc.xerox.com id <3141>; Mon, 14 Jan 1991 10:22:25 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Mon, 14 Jan 1991 10:22:12 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00061C15
Message-ID: <cbYTPIUB0KJLFOXx8g@lambda.parc.xerox.com>
Date:	Mon, 14 Jan 1991 18:22:12 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows.parc@xerox.com
Subject: MOO-Cows archives

I keep copies of all messages sent to the MOO-Cows mailing list.  A file
containing everything sent in 1990 is available for FTP in
[arisia.parc.xerox.com]pub/MOO-Cows-1990.txt.

I will occasionally make up files of more recent messages and leave them
in the same directory with names beginning with 'MOO-Cows'.

Enjoy!

	Lambda/Haakon

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6835>; Mon, 14 Jan 1991 16:50:15 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <19912>; Mon, 14 Jan 1991 16:49:44 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <19865>; Mon, 14 Jan 1991 16:48:28 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA19392; Tue, 15 Jan 91 11:18:25 EST
Posted-Date: Tue, 15 Jan 91 11:44:27 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Tue, 15 Jan 91 11:44:27 EST
X-To: MC
X-Cc: Safer Recycling Procedures
X-NS-Transport-ID: 08002008D0FD000622BE
Message-ID: <9101150018.AA19392@anu.anu.edu.au>
Date:	Tue, 15 Jan 1991 08:44:27 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: An idea for the @recycle verb: put a delay in between when the verb is called

and when the object is irrecoverable. Haakon asked me to send this to MOO-Cows
for further debate.

1. A modification to $room:@recycle

(Why is everything on the room? Surely this should be on player, shouldn't it?
This could be a good subject for debate in its own right. Where should verbs
go?)

around the lines:
  8:    result = recycle(dobj);
  9:    if (typeof(result) == ERR)
 10:      player:tell(result);
 11:    else
 12:      player:tell(name, " (", dobj, ") recycled.");
 13:    endif

add the construct:
        dobj.recycling=1;
        player:tell(dobj.name," (",dobj,") scheduled for recycling.");
        fork (500)
          if (dobj.recycling)
            <insert lines 8-13 here>
          endif
        endfork

Then you need the flag recycling on #1, and a verb @rescue that resets the
recycling flag. This is a simple change that will make recycling a lot safer.
While we are at it, I fail to see why recycling a parent should result in the
death of all its offspring. I'm not suggesting a MOO orphanage, but the
children should be taken care of by their grandparent.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn
------------------------------------------------------------------------------
"I see the country, far away
 Where I shall never stand.
 The heart goes where no footstep may
 Into the promised land."		-- A.E. Housman

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 17:58:17 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <18186>; Mon, 14 Jan 1991 17:57:47 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <20009>; Mon, 14 Jan 1991 17:56:52 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA11506; Mon, 14 Jan 91 17:56:03 -0800
X-NS-Transport-ID: 08002008D0FD00062389
In-Reply-to: "<9101150018.AA19392@anu.anu.edu.au> \"DXB105@phys.anu.edu.au\"  "
Message-ID: <9101150156.AA11506@belch.Berkeley.EDU>
Date:	Mon, 14 Jan 1991 17:56:03 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	DXB105@phys.anu.edu.au
cc:	MOO-Cows.parc@xerox.com
Subject: An idea for the @recycle verb: put a delay in between when the verb is called

I like the idea of a delay in the actual recycling.  I would make the
delay fairly big; say 12 hours or something.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6853>; Mon, 14 Jan 1991 18:21:40 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <18289>; Mon, 14 Jan 1991 18:17:19 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <18294>; Mon, 14 Jan 1991 18:16:15 PST
Received: by watcgl.waterloo.edu
	id <AA08510>; Mon, 14 Jan 91 21:14:56 EST
X-NS-Transport-ID: 08002008D0FD000623B2
Message-ID: <9101150214.AA08510@watcgl.waterloo.edu>
Date:	Mon, 14 Jan 1991 18:14:56 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	DXB105@phys.anu.edu.au, MOO-Cows.parc@xerox.com
Subject: Re:  An idea for the @recycle verb

i've been thinking that creating and recycling an object should
probably send an appropriate message to the object.  @create would
call new = create(parent) then new:create() or new:init().
@recycle would call object:recycle() then recycle(object).  this
would allow exits to clean up after themselves and so on.  in
fact, it's necessary in 2.0 to allow recycled objects to remove
themselves from contents lists, etc.

delaying the recycle i'm not too fond of, but since it's being done
without hacking the server, i won't complain :)

-- stephen/ghond

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6854>; Mon, 14 Jan 1991 18:21:42 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <18291>; Mon, 14 Jan 1991 18:18:32 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <18287>; Mon, 14 Jan 1991 18:17:03 PST
Received: by watcgl.waterloo.edu
	id <AA08520>; Mon, 14 Jan 91 21:16:18 EST
X-NS-Transport-ID: 08002008D0FD000623B4
Message-ID: <9101150216.AA08520@watcgl.waterloo.edu>
Date:	Mon, 14 Jan 1991 18:16:18 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	DXB105@phys.anu.edu.au, MOO-Cows.parc@xerox.com
Subject: Re:  An idea for the @recycle verb

oops, forgot to add: making recycle a message to be passed to the soon-to-
be recycled object would make it possible to re-chparent() each instance to
the grandparent, also.

-- stephen/ghond

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 18:33:29 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <20010>; Mon, 14 Jan 1991 18:33:07 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <18251>; Mon, 14 Jan 1991 18:31:18 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA11547; Mon, 14 Jan 91 18:31:11 -0800
X-NS-Transport-ID: 08002008D0FD000623DC
Message-ID: <9101150231.AA11547@belch.Berkeley.EDU>
Date:	Mon, 14 Jan 1991 18:31:11 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	MOO-Cows.parc@xerox.com
Subject: some ideas of mine

1) All objects should have some sort of a '@help' verb.  At the very
simplest level it would simply spew out the contents of the help_msg
property.  I suppose you could get fancy and merge it with the new
examine command.  What I'm after is a way for programmers to be able
to explain how an object is expected to be used, how to set up the
properties, etc. for an object they expect to be used as the parent in
a @create.

2) A poor man's version of callers(); all objects would have a list of
triggers.  Whenever a player (or perhaps any object) is added to or
removed from a room's contents list the room would call each object's
trigger for each object in the room that has a non-empty trigger list.
In the simplest case the object would have two triggers; one for when
players are added to the room's contents list and another for when
players are removed from it.

3) It would be nice if there were some wharehouse room where
programmers could 'dump' their objects they expect others to use as
the parent for @create.  This would make it easy for players to find
out what is readily available and hopefully reduce a lot of wheel
reinventing.

4) In tinymud all objects (room, exit, player, or thing) had success
and fail messages.  The success message was shown to the player if
they successfully used the object; if the object was locked to
something they had to be in possesion of that something in order to
successfully use the object.  If the object wasn't locked then (in
general) a player could always successfully use the object.  In the
case of a room, 'using' the room meant simply doing a 'look'; look
always showed the room's description, and if it wasn't locked and it
had a success message, you'd see that as well.  (Builders sometimes
used this to get around the 512 char limit on descriptions.)  Anyhow,
I was just wondering if such a facility would be useful on Lambda, for
example, for puzzles.  No doubt you can achieve the same effect, but
less crudely with existing facilities.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 18:54:10 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <18323>; Mon, 14 Jan 1991 18:53:44 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <18319>; Mon, 14 Jan 1991 18:52:41 PST
Received: by watcgl.waterloo.edu
	id <AA09272>; Mon, 14 Jan 91 21:52:18 EST
X-NS-Transport-ID: 08002008D0FD00062414
Message-ID: <9101150252.AA09272@watcgl.waterloo.edu>
Date:	Mon, 14 Jan 1991 18:52:18 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	MOO-Cows.parc@xerox.com, rusty@belch.berkeley.edu
Subject: Re:  some ideas of mine

> 1) All objects should have some sort of a '@help' verb.  At the very
> simplest level it would simply spew out the contents of the help_msg
> property.  I suppose you could get fancy and merge it with the new
> examine command.  What I'm after is a way for programmers to be able
> to explain how an object is expected to be used, how to set up the
> properties, etc. for an object they expect to be used as the parent in
> a @create.

good plan.  whether people will use it:  see programming libraries on
tinymuck's.

> 2) A poor man's version of callers(); all objects would have a list of
> triggers.  Whenever a player (or perhaps any object) is added to or
> removed from a room's contents list the room would call each object's
> trigger for each object in the room that has a non-empty trigger list.
> In the simplest case the object would have two triggers; one for when
> players are added to the room's contents list and another for when
> players are removed from it.

i don't understand what this would be useful for, but it would be
possible, i suppose.

> 3) It would be nice if there were some wharehouse room where
> programmers could 'dump' their objects they expect others to use as
> the parent for @create.  This would make it easy for players to find
> out what is readily available and hopefully reduce a lot of wheel
> reinventing.

the .findclass (@classes on lambda) command is designed to do this.
location of generic objects is irrelevant, imo.

> 4) [about room @succ messages on tinymud's]

i'd suggest re-programming the look function on the room class.
if you don't want it on all rooms, make a "tinymud-room" class.
if you don't like the 512-char (or whatever it is currently) limit
on desc's, change descriptions to lists-of-strings and you've got
unlimited length.

-- stephen/ghond

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 19:08:06 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <20008>; Mon, 14 Jan 1991 19:07:49 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <20009>; Mon, 14 Jan 1991 19:06:31 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA11600; Mon, 14 Jan 91 19:06:13 -0800
X-NS-Transport-ID: 08002008D0FD0006242B
In-Reply-to: "<9101150252.AA09272@watcgl.waterloo.edu> \"sfwhite@watcgl.waterloo.edu\"now, we'"
Message-ID: <9101150306.AA11600@belch.Berkeley.EDU>
Date:	Mon, 14 Jan 1991 19:06:13 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	sfwhite@watcgl.waterloo.edu
cc:	MOO-Cows.parc@xerox.com
Subject: some ideas of mine

The idea behind my poor man's version of callers() is for objects to
be able to respond/react to players arriving and leaving.  For
example, my dog Pickles could start barking when someone enters the
room.  But perhaps there's a better way to do it that I'm unaware of.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <hpb.cis.pitt.edu!hobbes>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6838>; Mon, 14 Jan 1991 19:25:54 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <20012>; Mon, 14 Jan 1991 19:25:37 PST
Received: from hpb.cis.pitt.edu ([130.49.6.51]) by alpha.xerox.com with SMTP id <18319>; Mon, 14 Jan 1991 19:24:30 PST
Received: by hpb.cis.pitt.edu (5.57/Ultrix2.4-C)
	id AA14284; Mon, 14 Jan 91 22:23:28 EST
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD00062459
In-Reply-to: "<9101150306.AA11600@belch.Berkeley.EDU>; from \"Rusty Wright\" at Jan 14, 91 7:06 pmng i"
Message-ID: <9101150323.AA14284@hpb.cis.pitt.edu>
Date:	Mon, 14 Jan 1991 19:23:26 PST
From:	hobbes@hpb.cis.pitt.edu (The Rain In Spain Falls Mainly On The Plane)
To:	rusty@belch.berkeley.edu (Rusty Wright)
cc:	MOO-Cows.parc@xerox.com
Subject: Re: some ideas of mine

-> 
-> The idea behind my poor man's version of callers() is for objects to
-> be able to respond/react to players arriving and leaving.  For
-> example, my dog Pickles could start barking when someone enters the
-> room.  But perhaps there's a better way to do it that I'm unaware of.
-> 
seems to me you just grab the tell on the dog, when it sees a 
'<soandso> has arrived.' message, it starts barking...personally, I think
this is annoying as all get out, I hate dogs, but..:->


-- 
hobbes@hpb.cis.pitt.edu     | "My moral standing is lying down" - NIN
wbfst1@unix.cis.pitt.edu    | "I used to think that love was sensible" - IS
Tigger@zets (where's that?) | "What you say should be from your own mind!" - NE

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <csc2.anu.edu.au!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 19:30:29 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <20007>; Mon, 14 Jan 1991 19:30:20 PST
Received: from csc2.anu.edu.au ([130.56.4.25]) by alpha.xerox.com with SMTP id <20007>; Mon, 14 Jan 1991 19:29:03 PST
Received: by csc2.anu.edu.au (4.0/1.0)
	id AA03588; Tue, 15 Jan 91 14:27:56 EST
X-NS-Transport-ID: 08002008D0FD00062461
Message-ID: <9101150327.AA03588@csc2.anu.edu.au>
Date:	Tue, 15 Jan 1991 11:27:56 PST
From:	tja105@csc2.anu.edu.au ("Timothy J Allen")
To:	MOO-Cows.parc@xerox.com
Subject: Re : some ideas of mine

Gus wants arrivals and departures to trigger botjects. You can do this by
listening for the appropriate messages, and searching through callers to see
if the message really does correspond to someone coming or going. I gather
that Gary's bodyguard does something like this. This does take quite a bit
of programming expertise; perhaps someone should make a generic arrival/
departure monitor so beginners can instantiate it.

As far as long descs are concerned, there is no limit on the length of a
string that I'm aware of, though consideration for the inadequacy of most
clients mandates that it not be too much greater than 512 characters. However,
a description can be a list, so you can pack as many strings into it as you
like. There's no need for succ's or the like. BTW Ghond, your code apparently
had a 1024-char limit assumed but not tested for. Tsk tsk :-).
_______________________________________________________________________________
Tim Allen (Gemba)                              tja105@csc2.anu.edu.au
Theoretical Physics
RSPhysS,ANU                     Don't woodchip the Lyman Alpha forest

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 19:41:53 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <20018>; Mon, 14 Jan 1991 19:41:27 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <20015>; Mon, 14 Jan 1991 19:40:24 PST
Received: by watcgl.waterloo.edu
	id <AA10321>; Mon, 14 Jan 91 22:40:05 EST
X-NS-Transport-ID: 08002008D0FD0006247D
Message-ID: <9101150340.AA10321@watcgl.waterloo.edu>
Date:	Mon, 14 Jan 1991 19:40:05 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	MOO-Cows.parc@xerox.com, tja105@csc2.anu.edu.au
Subject: Re: some ideas of mine

i stand corrected; there is no limit on string property lengths.  i
was referring to the string lengths in the interface code.

p.s.  it's very bad form to insult someone's code on usenet or a
      mailing list.  it's about as intelligent as a spelling flame,
      and about as useful.  post the fix yourself or mail to the
      author.  (these are called "bug reports", by the way).

-- stephen/ghond

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 19:43:57 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <20015>; Mon, 14 Jan 1991 19:43:25 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <20015>; Mon, 14 Jan 1991 19:42:38 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA20766; Tue, 15 Jan 91 14:32:51 EST
Posted-Date: Tue, 15 Jan 91 14:39:35 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Tue, 15 Jan 91 14:39:35 EST
X-To: MC
X-Cc: Descriptions as lists
X-NS-Transport-ID: 08002008D0FD00062482
Message-ID: <9101150332.AA20766@anu.anu.edu.au>
Date:	Tue, 15 Jan 1991 11:39:35 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: ghond suggests that the best way to get around 512 character limits is to

change descriptions to lists of strings. Three points:

  1. Yes, it is.
  2. It's not quite the same, because it starts a new paragraph, but really,
	paragraphs shouldn't get too much longer anyway.
  3. This has in fact already been done in a few places around LambdaMOO (the
	built-in :description() verb handles it). It wasn't clear from ghond's
	statement whether he knew about this basically undocumented feature.
  4. It could be argued that :description() is the wrong place for the
	expansion and it really should be in #6:tell(). Certainly I have :-).
	At the moment, #6:tell() writes out lists as {list}. Comments?
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"It could be worse."
"Yeah. It could be raining." - `Promised Land', Brian Stableford

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6837>; Mon, 14 Jan 1991 19:52:01 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <20017>; Mon, 14 Jan 1991 19:51:48 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <20034>; Mon, 14 Jan 1991 19:50:42 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA20815; Tue, 15 Jan 91 14:42:48 EST
Posted-Date: Tue, 15 Jan 91 14:47:22 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Tue, 15 Jan 91 14:47:22 EST
X-To: MC
X-Cc: Arrivals and Departures
X-NS-Transport-ID: 08002008D0FD0006249A
Message-ID: <9101150342.AA20815@anu.anu.edu.au>
Date:	Tue, 15 Jan 1991 11:47:22 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: ***


>Gus wants arrivals and departures to trigger botjects. You can do this by
>listening for the appropriate messages, and searching through callers to see
>if the message really does correspond to someone coming or going. I gather
>that Gary's bodyguard does something like this. This does take quite a bit
>of programming expertise; perhaps someone should make a generic arrival/
>departure monitor so beginners can instantiate it.

That's the clever way. The brute-force approach is to maintain an internal list
of the room contents, and check for consistency every time the tell is
triggered. Then it doesn't matter how they arrived. Remember to fork it off,
though, in case the announce predates the actual arrival.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
		MOO:	Gary_Severn et al
------------------------------------------------------------------------------
"It is the logic of our times
 No subject for immortal verse
 That we, who lived by honest dreams
 Defend the bad against the worse."	-- C.D. Lewis

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6862>; Tue, 15 Jan 1991 10:20:13 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16166>; Tue, 15 Jan 1991 10:15:00 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16163>; Tue, 15 Jan 1991 10:13:42 PST
Received: by lambda.parc.xerox.com id <3141>; Tue, 15 Jan 1991 10:14:45 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Tue, 15 Jan 1991 10:14:34 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00062A1D
Message-ID: <cbYoO_UB0KJLRmKpwg@lambda.parc.xerox.com>
Date:	Tue, 15 Jan 1991 18:14:34 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows.parc@xerox.com
Subject: Re: An idea for the @recycle verb

I'm also not fond of delaying the recycle, at least not for more than
about 30 seconds.  Remember, some folks will be doing the recycle in
order to free up some quota to build something they like better.  Making
the recycle wait for a long time (didn't someone advocate delaying for a
full day?) seems needlessly frustrating.

Perhaps a better approach than delaying is something along the lines of
how file-deletion worked in TOPS-20, for example.  That is, when you
delete a file it is only MARKED for deletion.  Only logging out or
typing a 'purge' command forced all marked files actually to be deleted.

Ghond brings up the idea of :recycle and :initialize verbs that are
called by the @recycle and @create commands.  Based on an idea from
Frand, I was already intending to add calls to such verbs from inside
the implementation of the functions recycle() and create().  There are
some amusing possibilities for lossage if, for example, the :recycle
verb itself calls recycle() on the same object, but it's reasonably easy
for the server to protect itself.

I favor putting the calls to :recycle and :initialize in the primitives,
not in the commands; I expect to see a number of objects created by
MOO-code rather than humans typing commands and it seems a shame for all
of those pieces of code to have to include appropriate calls.  On the
other hand, I mightn't mind adding optional arguments to create() and
recycle() allowing the caller to prevent the calls to :recycle and
:initialize.

As for the notion of reparenting children to the grandparent before
recycling the parent, I think I agree with Gary on this one. 
Automatically recycling the children has always seemed a bit drastic to
me.  Ghond, did you have a philosophical/methodological reason for doing
it the way it is?

	Pavel

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6864>; Tue, 15 Jan 1991 10:40:20 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16174>; Tue, 15 Jan 1991 10:32:42 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16185>; Tue, 15 Jan 1991 10:31:16 PST
Received: by lambda.parc.xerox.com id <3141>; Tue, 15 Jan 1991 10:32:01 PST
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Tue, 15 Jan 1991 10:31:59 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD00062A54
Message-ID: <4bYoeTYB0KJLJmKqIl@lambda.parc.xerox.com>
Date:	Tue, 15 Jan 1991 18:31:59 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows.parc@xerox.com
Subject: Re: some ideas of mine

I'm not sure about a separate @help verb on all objects.  I could,
however, support having 'examine' call some verb to acquire instructions
on using the object.  Perhaps that could replace the current list of
'obvious' verbs, which would just be the default...

As for the so-called 'poor man's version of callers()' (a name that I
don't understand for this issue), we could, I suppose, make the default
'enterfunc' and 'exitfunc' call some verb on everything in the room.  Is
it really worth it?  You could simply do what Gary suggests and maintain
a list of the players in the room, updating it and taking appropriate
actions on every :tell.  The application seems too uncommon at the
moment to warrant a general solution.

I agree with Ghond about the lack of a need for a warehouse room. 
@classes is a fine mechanism for public class identification.

I don't think that we really need generic 'succ' and 'fail' messages a
la TinyMUD.  We have a wider variety of more specific messages.  As for
locking, we have a fully general mechanism in place, via the
:is_locked_against verb defined on all objects.  The default
implementation of that verb uses two lists of objects, .locked_to and
.locked_against.  The @lock and @unlock commands make it reasonably easy
to manipulate those lists.

On the subject of string-length limitations, LambdaMOO has none at all,
either in the programming language interpreter or in the network
interface code; I went to a certain amount of trouble to implement a
little 'streams' package and to use it for all arbitrary-length string
manipulations.  Thus, there's no need for extra messages to help get
around such limitations.  I feel sorry for those who use clients that
are limited to 512-character lines, but not sorry enough to be careful
about limiting the length of my messages.

Finally, I agree with Gary that :description is the wrong place for
accomodating the convention that lists of strings are to be treated as
multiple paragraphs/lines.  I would even agree that it shouldn't be done
in :look_self, which is where it really was happening.  Instead, I
abstracted out that part of the code into the verb :tell_lines, which
takes a single argument, either a string or a list of strings, and does
one or more :tell calls.  I think that this is better than overloading
:tell with this job.  Since :tell takes multiple arguments and
concatenates them into a single line, it seems to me that adding in the
list-of-strings job would excessively complicate the statement of its
contract to the rest of the system.  I prefer a larger number of verbs
with simpler descriptions over the reverse.  I believe that this
philosophy makes a system easier to understand and to use.

	Pavel

PS - I agree with Ghond that it is inappropriate to use this forum (or,
in general, any forum) to take cheap shots at someone else's code,
especially when one is not in possession of the complete story about
that code.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lucid.com!yduj>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7066>; Tue, 15 Jan 1991 21:56:09 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16240>; Tue, 15 Jan 1991 21:53:40 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16240>; Tue, 15 Jan 1991 21:51:20 PST
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA09913g; Tue, 15 Jan 91 21:49:36 PST
Received: by boston-harbor id AA02968g; Wed, 16 Jan 91 00:51:57 EST
X-NS-Transport-ID: 08002008D0FD00063228
In-Reply-to: "Rusty Wright's message of Mon, 14 Jan 1991 17:56:03 PST <9101150156.AA11506@belch.Berkeley.EDU>"
Message-ID: <9101160551.AA02968@boston-harbor>
Date:	Tue, 15 Jan 1991 21:51:57 PST
From:	Judy Anderson <yduj@lucid.com>
To:	rusty@belch.berkeley.edu
cc:	DXB105@phys.anu.edu.au, MOO-Cows.parc@xerox.com
Subject: An idea for the @recycle verb: put a delay in between when the verb is called

Hmmm.  I don't know if I want to get involved in MOO flaming...  but a
12 hour delay on recycles means you better update @quota at the time
of @recycle, before the space is reclaimed.  I imagine this allows a
user to circumvent the quota system.  But, for example, I created and
recycled several birthday cakes before I got the code right.  If I'd
run out of quota during that time I would have been seriously bummed.
I'm not sure what the correct solution is, but you should be aware of
this limitation while considering delays on recycles.

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6869>; Tue, 15 Jan 1991 12:21:36 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <16206>; Tue, 15 Jan 1991 12:21:27 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA16841; Tue, 15 Jan 91 12:21:11 -0800
Message-Id: <9101152021.AA16841@belch.Berkeley.EDU>
In-Reply-To: <cbYoO_UB0KJLRmKpwg@lambda.parc.xerox.com> "pavel@parc.xerox.com"
Date:	Tue, 15 Jan 1991 12:21:11 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	pavel@parc.xerox.com
Cc:	MOO-Cows.parc@xerox.com
Subject: An idea for the @recycle verb

I was the one that suggested the delaying of the recycle, but I meant
it in the way you suggested with respect to the way TOPS-20 does it.
My intent is in providing some sort of safety net for people who
accidently recycle the wrong thing.  I like the idea of a purge
command.  I would combine it with a delay; if you explicitly issue a
purge command it does all the recycles that are pending, otherwise
they are recycled after some well-advertised period.  Doing a purge on
disconnects could be dangerous because people get disconnected due to
network problems.

On a related topic of recycling, I think that you're going to get
tired of manually increasing players' quotas and I'm wondering what
thoughts you have on having quotas increased automatically.  I was
thinking about quotas back in the good old tinymud days, primarily as
a means of preventing people intent on crashing the server from doing
so.  In my scheme, you had a quota Q, a time period T, and an
increment I.  Once a user hit their quota, after time period T their
quota would automatically be bumped up by I, so their new Q would be
their old Q + I.  With tinymud T and I would probably be global, and Q
would be per-player, but with MOO T and I can also be per player.  You
could also have another value M, for a max quota; Q can never exceed M
and you'd need a wizard to bump up M.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <phys.anu.edu.au!DXB105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7066>; Tue, 15 Jan 1991 19:45:25 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16232>; Tue, 15 Jan 1991 19:44:56 PST
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <16232>; Tue, 15 Jan 1991 19:43:14 PST
Received: by anu.anu.edu.au (5.57/1.0)
	id AA08809; Wed, 16 Jan 91 13:02:45 EST
Posted-Date: Wed, 16 Jan 91 13:24:25 EST
Received: from PHYS.DECnet by ANU.DECnet with MAIL-11
	(utk-mail11d v1.6); Wed, 16 Jan 91 13:24:24 EST
X-To: MC
X-Cc: Various Things
X-NS-Transport-ID: 08002008D0FD00063138
Message-ID: <9101160202.AA08809@anu.anu.edu.au>
Date:	Wed, 16 Jan 1991 10:24:25 PST
From:	David Bofinger <DXB105@phys.anu.edu.au>
To:	MOO-Cows.parc@xerox.com
Subject: .

>[...] having 'examine' call some verb to acquire instructions
>on using the object.  Perhaps that could replace the current list of
>'obvious' verbs, which would just be the default...

Gary_Severn votes YES. There should be some way to disable that verb listing,
anyway. Examine is a pretty horrid verb, really, from a VR standpoint.
Incidentally, is there any good reason examine calls description()? I would,
instinctively, have kept it lean and mean, just usage output.

>The application seems too uncommon at the moment to warrant a general solution.

In my experience, the application is pretty common. But the fix is easy, so in
practice I agree with Lambda.

>I agree with Ghond about the lack of a need for a warehouse room. 
>@classes is a fine mechanism for public class identification.
 
Errr... what is a public class? Any object that has been set readable? On
alphaMOO there was a concept of a public class, but I thought Lambda axed it.

>[comments on locking being OK as it is.]
A lot of people seem to think I was criticising locking. Actually, I was using
it as an example of how something _should_ work. Never mind.

>PS - I agree with Ghond that it is inappropriate to use this forum (or,
>in general, any forum) to take cheap shots at someone else's code,
>especially when one is not in possession of the complete story about
>that code.

Let this be a lesson to you Gemba, next time use more smileys. :) :) :) :) :)

>Perhaps a better approach than delaying is something along the lines of
>how file-deletion worked in TOPS-20, for example.  That is, when you
>delete a file it is only MARKED for deletion.  Only logging out or
>typing a 'purge' command forced all marked files actually to be deleted.
 
Have a purge command instead of/as well as a timed recycle, sure. But remember
some people log out involuntarily.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"We use the classical theory on Mondays, Wednesdays and Fridays, and the
quantum theory on Tuesdays, Thursdays and Saturdays." -- Sir William Bragg

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5611>; Wed, 16 Jan 1991 21:57:58 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16372>; Wed, 16 Jan 1991 21:57:51 PST
Received: by watcgl.waterloo.edu
	id <AA24860>; Thu, 17 Jan 91 00:57:18 EST
Message-Id: <9101170557.AA24860@watcgl.waterloo.edu>
Date:	Wed, 16 Jan 1991 21:57:18 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	MOO-Cows.parc@xerox.com, pavel@parc.xerox.com
Subject: Re: An idea for the @recycle verb

umm, to be honest, i can't recall *why* i recursively recycled the
children of a recycled object.  i think it was because recycle() was
written before chparent().  anyway, there's no reason that you can't
simply chparent() them to the grandparent automatically (i'll probably
make this change in 2.0).

-- stephen/ghond


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7810>; Wed, 30 Jan 1991 23:05:16 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <20008>; Wed, 30 Jan 1991 23:04:32 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <17993>; Wed, 30 Jan 1991 23:03:29 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA19641; Wed, 30 Jan 91 23:03:20 -0800
X-NS-Transport-ID: 08002008D0FD0006CBEB
Message-ID: <9101310703.AA19641@belch.Berkeley.EDU>
Date:	Wed, 30 Jan 1991 23:03:20 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	MOO-Cows.parc@xerox.com
Subject: what makes for good parent objects?

(By "parent objects" I mean the things listed by @classes.)

When I make an object that I plan to use as a parent for other objects
one of the things I do is try to have as few strings as possible
inside the verb and instead have them be _msg properties on the
object.  For example, when a player sits on my chair one of the things
the sit verb does is a "player:tell(this.sit_succ_msg);".

Perusing some of the object listed by @classes I don't see very many
that use _msg properties in this manner.  Am I just being "property
anal retentive"?  It seems to me that having the strings be on _msg
properties is that it makes customizing the object easier, but maybe
there are disadvantages that I'm not aware of?

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <hpb.cis.pitt.edu!hobbes>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <7813>; Thu, 31 Jan 1991 08:52:56 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <20442>; Thu, 31 Jan 1991 08:52:38 PST
Received: from hpb.cis.pitt.edu ([130.49.6.51]) by alpha.xerox.com with SMTP id <20451>; Thu, 31 Jan 1991 08:45:09 PST
Received: by hpb.cis.pitt.edu (5.57/Ultrix2.4-C)
	id AA08758; Thu, 31 Jan 91 11:39:29 EST
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD0006D31B
In-Reply-to: "<9101310703.AA19641@belch.Berkeley.EDU>; from \"Rusty Wright\" at Jan 30, 91 11:03 pm"
Message-ID: <9101311639.AA08758@hpb.cis.pitt.edu>
Date:	Thu, 31 Jan 1991 08:39:28 PST
From:	hobbes@hpb.cis.pitt.edu (The Rain In Spain Falls Mainly On The Plane)
To:	rusty@belch.berkeley.edu (Rusty Wright)
cc:	MOO-Cows.parc@xerox.com
Subject: Re: what makes for good parent objects?

Rusty Wright
-> 
-> Perusing some of the object listed by @classes I don't see very many
-> that use _msg properties in this manner.  Am I just being "property
-> anal retentive"?  It seems to me that having the strings be on _msg
-> properties is that it makes customizing the object easier, but maybe
-> there are disadvantages that I'm not aware of?
-> 
I write code that uses such messages (@show the verbs on #1150, but they 
aren't quite correct, I need to fuck around a tad bit more) usually...
however, if there are messages you don't want the user to change (I can't
think of any, except maybe 'I can't go that way' messages) you prolly
otta hard code them.

I don't use the ...._msg format, however, I just kinda slap the name in,
such as drive, odrive, etc...

-- 
hobbes@hpb.cis.pitt.edu     | "My moral standing is lying down" - NIN
wbfst1@unix.cis.pitt.edu    | "I used to think that love was sensible" - IS
Tigger@zets (where's that?) | "What you say should be from your own mind!" - NE

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lucid.com!yduj>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5578>; Tue, 5 Feb 1991 18:51:51 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16829>; Tue, 5 Feb 1991 18:50:10 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16876>; Tue, 5 Feb 1991 18:48:40 PST
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA20029g; Tue, 5 Feb 91 18:43:34 PST
Received: by boston-harbor id AA07875g; Tue, 5 Feb 91 21:46:56 EST
X-NS-Transport-ID: 08002008D0FD00070D4D
Message-ID: <9102060246.AA07875@boston-harbor>
Date:	Tue, 5 Feb 1991 18:46:56 PST
From:	Judy Anderson <yduj@lucid.com>
To:	MOO-Cows.parc@xerox.com
Subject: DOCUMENTATION!

I have just written the "tinymud and lambdamoo comparison" document.
It was created by taking Three's guide to mud and deleting a lot of
stuff.  Additions and any corrections are welcome.  This will either
end up as "help tinymud" in LambdaMOO or as a standalone document to
be FTP'd.

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'
-------------------------------------
This is a list of tinymud commands and their equivalents in LambdaMOO.
The original list of commands comes from "Three's Unabridged
Dictionary of Commands", available from belch.berkeley.edu.  This is
not a comprehensive document.  You must refer to the programmer's
manual or the online documentation in LambdaMOO for more information
on specific commands.  --yduJ

The following commands are basically the same in MOO and MUD.

DROP(THROW), GET(TAKE), GO, GRIPE, HELP, HOME, INVENTORY, LOOK, QUIT, SAY (",:)

The following commands have no equivalent:
KILL, ROB, SCORE, @FORCE


EXAMINE
Examine displays the object's name, number, its owner, and the
"obvious verbs" (the commands you could expect to work with this
object, which may be arbitrary words defined by the author of the
object).

GIVE
This allows you to give an object to a player.  Pennies are not a
supported concept in MOO.

GOTO
This is called "GO".  GOTO doesn't exist.  MOVE doesn't exist either.

KILL
This command does not exist.  Let's be nice, shall we?  Actually, the
weapons used in the roleplaying system in LambdaMOO define a KILL
verb, to be used on the various monsters that may be encountered on an
adventure.  However, this KILL doesn't have anything to do with the
standard mud KILL.

NEWS
In LambdaMOO, the news is maintained through the newspaper object in
the living room.  Read this object periodically for news updates.  The
date last updated is printed in the newspaper.

PAGE
page <player> [<message>]
Basically the same.  Unlike MUSH, you don't include an = between
player and message.

QUIT
QUIT sends you home before it disconnects you.  (Your possessions
remain with you.)

READ
Unlike mud, this is not a synonym for look.  Objects which may be read
define the verb READ, and don't just print out their description.

WHISPER
whisper "message in quotes" to player
The syntax is changed, but the command does the same.

WHO
This has been renamed @who (any capitalization works), and gives
more information than the standard mud WHO.  The WHO flags don't exist.

@CHOWN
This concept doesn't exist in MOO.  Instead, you should consult the
MOO Programmer's Manual for enlightenment about the wonders of object
oriented programming.

@CREATE
@create <predefined-object or objectnumber> named <name>
Create a child of an existing object.  Predefined objects are: note,
container, and thing.  Some objects are also accessed as $objectname.
The rest are accessed by object number.  Nonprogrammers may only
@create predefined objects.

@DESCRIBE
This is accessed as DESCRIBE <object> AS "quoted string".

@DIG
@dig <new-room-name>
or  @dig <exit-description> to <new-room-name-or-old-room-object-number>
An exit description is outboundname[,synonyms]|inboundname[,synonyms]
or just outboundname[,synonyms]  The forms with exits create those
exits as well as the room, so that later linking is unnecessary.

@FAIL
@take_failed <object> is "quoted string" defines the failure message
for things .
@nogo <object> is "quoted string" defines the failure message for exits.

@FIND
@audit is the equivalent on MOO.

@LINK
Mostly this should be obviated by @dig, see above.  
You set your home with @sethome.  You must be in your proposed home.
Drop-tos are an unsupported concept.
@add-exit and @add-entrance manipulate links when an exit can't be
added because the attempting builder does not own the destination.

@LOCK
@lock <object> {to | against} {nothing | <object>}
When an object(1) is locked TO an object(2), you must be or have that
object(2) in order to be allowed to use that object(1).  If it is
locked AGAINST object(2), you must NOT be etc.

@NAME
@rename is the equivalent verb.

@OFAIL
@onogo object is "quoted string" is the equivalent command for exits.
There is no equivalent for "take".  Use verbs instead.

@OPEN
No equivalent.  Use @dig.

@OSUCCESS
@oleave is the equivalent for exits, to be printed in the room left.
@oarrive is the equivalent for exits, to be printed in the room entered.

@PASSWORD
@password <old password> <new password>.  Just a syntax change.

@SET
This doesn't have any one equivalent.

@STATS
There is no equivalent for this.  However, in LambdaMOO a statistics
gathering device has been created.

@SUCCESS
@leave is the equivalent for exits, to be printed before leaving.
@arrive is the equivalent for exits, to be printed after arriving.

@TELEPORT
Use @move.

@TOAD
We don't need no steenking toads!

@UNLINK
@fill is the opposite of @dig, but this command is still under development.

@UNLOCK
Similar syntax to @LOCK.  See @LOCK above.


Here is an attempt at changes to Three's encyclopaedia of MUD terms.
Again, it is not comprehensive.
-------------------------------------

BOGUS COMMANDS
Do not use exits to make bogus commands!  Use verbs!  See the
LambdaMOO Programmer's manual.

DESTROYING
Use @recycle

DROP-TOs
Drop-to's don't exist.  However, by judicious use of verbs you can get
the same effect.

FAILURE
Failure is not a generic aspect.  Verbs allow a great variety of
partial success and failure responses.

FLAGS
Flags don't really exist in MOO.  Instead, objects have properties,
arbitrary named slots that may contain values.  Some MUD flags don't
have any equivalent in MOO.  Other MUD flags don't make any sense in
MOO.

WIZARD
Wizards are pretty much the same in MOO as MUD.  They can do anything.

DARK
If a room is DARK, then you can't see any of its contents.  Only
applies to rooms.  Currently it can only be set by evaluating programs
in the parser (see the programmers manual).

GENDER
@gender <male|female|neuter> sets your own gender.  Genders of objects
is trickier (you have to do some programming.)

MONEY
There is no money in LambdaMOO.  Instead, there is a building quota system.

SUBSTITUTIONS
This works just like MUD for the @o versions of messages.  You can
also get pronoun substitution for programming purposes with the
$string_utils:pronoun_sub function.  See the manual.

SUCCESS
Like failure, this doesn't make as much generic sense in MOO as it
does in MUD.

TYPES OF OBJECTS
There are an ENORMOUS number of types of objects.  See the programming
manual. 


From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5578>; Tue, 5 Feb 1991 21:02:02 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16343>; Tue, 5 Feb 1991 20:59:59 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <16625>; Tue, 5 Feb 1991 20:58:04 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA21587; Tue, 5 Feb 91 20:56:29 -0800
X-NS-Transport-ID: 08002008D0FD00070E45
Message-ID: <9102060456.AA21587@belch.Berkeley.EDU>
Date:	Tue, 5 Feb 1991 20:56:29 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	MOO-Cows.parc@xerox.com, yduj@lucid.com
Subject: Re:  DOCUMENTATION!

For @dig, the last sentence should explicitly say that the exits are
linked as well.  E.g., something along the lines of "The forms with
exits create those exits as well as the room and create all of the
necessary links between the rooms and exits."

I'm not sure if it's relevant to non-programmers, but any string
property with a name of the form something_msg can be set with

	@something object is "some string"

I.e., chop off the _msg and prepend a @.  This implies that there's
essentially an unlimited number of @ commands.

I would add something to the introductory paragraph explaining how
each object and room can define its own commands (and mention that
they're called verbs on MOO), and mention that the examine command
will list the available commands on objects and rooms.  Saying this up
front should pique the interest of people who don't know why they
might be interested in MOO vs. mush or muck.

On the subject of @lock; I think there's a bug in the container
object (#8).  I wrote my own container object (slightly different than
#8) and locked it so that people couldn't pick it up and walk off with
it.  I couldn't figure out why I couldn't put anything in it and then
I eyeballed #8 and decided to add its accept verb but that still
didn't help.  It turns out that #8's accept verb uses is_locked_against
which seems to be a mistake because if the container is locked to
anything then you can only put what it's locked to in it (as well as
only whatever it's locked to being able to pick it up).  I don't know
that this has any bearing on this document; I suppose you could say
that @lock provides a fairly simple locking mechanism and the
programmer of the object's verbs could do all sorts of locking things
not supported by @lock (for example, gender-specific rooms, i.e., rest
rooms).

Not related to this document; could you send me an example of the
drop-to code you alluded to?  I could use it to have the objects my
fridge dispenses recycle themselves when dropped.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <belch.berkeley.edu!rusty>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <5943>; Sun, 10 Feb 1991 13:01:05 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16998>; Sun, 10 Feb 1991 13:00:03 PST
Received: from belch.Berkeley.EDU ([128.32.152.202]) by alpha.xerox.com with SMTP id <17702>; Sun, 10 Feb 1991 12:58:14 PST
Received: by belch.Berkeley.EDU (5.57/1.41)
	id AA06689; Sun, 10 Feb 91 12:57:58 -0800
X-NS-Transport-ID: 08002008D0FD00074030
Message-ID: <9102102057.AA06689@belch.Berkeley.EDU>
Date:	Sun, 10 Feb 1991 12:57:58 PST
From:	rusty@belch.berkeley.edu (Rusty Wright)
To:	MOO-Cows.parc@xerox.com
Subject: LambdaMOO examples

I encourage you all to make a directory in pub/moo/LambdaMOO on belch
and upload your moo code so people can see how it's done.  Newcomers
are always eager to see examples.  I've uploaded my stuff into the
directory gus_stuff.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6064>; Wed, 27 Feb 1991 14:07:41 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16373>; Wed, 27 Feb 1991 14:07:02 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16369>; Wed, 27 Feb 1991 14:05:06 PST
Received: by watcgl.waterloo.edu
	id <AA01035>; Wed, 27 Feb 91 17:04:02 EST
X-NS-Transport-ID: 08002008D0FD0007F8B2
Message-ID: <9102272204.AA01035@watcgl.waterloo.edu>
Date:	Wed, 27 Feb 1991 14:04:02 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	MOO-Cows.PARC@xerox.com, lamping@parc.xerox.com
Subject: Re:  Lack in New Locking System?

Last night, I encountered a difficulty in using the new locking system.  I
wanted to programatically change the lock on an object (so that once you
throw food at someone, it sticks :-) ).  The only alternatives I could
think of were:

1. Cons up a string with the appropriate syntax and with object numbers put
in the right places, put it in iobjstr, and call @lock.  (Yuk!),

2. Build an instance of the key data structure.  (But now my verb depends
on the details of that representation, which I seem to have no reason to
have faith in.)

> I thought of three solutions [to allow dynamic locking]:

> A. The "right" solution would seem to be to reify thunks, so that pieces of
> code can be passed around as first class objects.  This sounds like one big
> effort, and I'm not volunteering.

i'm not sure what representation is used in lambdamoo, but in the
original, code was represented as a bunch of parse trees, using
pointers.  this was an easy hack that allowed both traversal of the
trees for execution, and for "unparsing" back into source.  problem
is, you can't move them around in memory or assign code to variables
without updating all the pointers.

the solution, of course, is to go to a stack-based execution, such as
in kernighan & pike's "hoc".  this would require a little more effort
to "unparse" to source, as the parse tree would have to be rebuilt
from RPN tokens.  not too tricky, though.

with this in place, code as a datatype becomes possible.

> B. An easier alternative would be to have the lock be an actual
> verb on the object, which @lock would set.  Then I can
> programmatically move code from the definition of obj:x to obj:y. 
> This solution means throwing out most of the new locking code, but
> isn't incompatible at the top level interface, and probably
> requires less code than currently.

i believe this is possible in both v2.0 (with the compile() primitve)
and lambdamoo (don't know what the primitive is called).  in fact,
this is the approach i used in the unfinished tinymud.db:  call
can_do on the object in question.

> C. The last alternative I see is to document constructor operations for the
> key forms.

i'm not quite sure what you mean here.  do you mean, document
the moo data structures used to represent keys?

-- stephen

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watnxt2.ucr.edu!rearl>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6092>; Thu, 28 Feb 1991 11:40:47 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16170>; Thu, 28 Feb 1991 11:39:57 PST
Received: from watnxt3.ucr.edu ([192.31.146.125]) by alpha.xerox.com with SMTP id <16426>; Thu, 28 Feb 1991 11:13:10 PST
Received: from  watnxt1.ucr.edu  (watnxt1) by  watnxt3.ucr.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09557; Thu, 28 Feb 91 09:53:31 PST
Received: from  watnxt2.ucr.edu  (watnxt2) by  watnxt3.ucr.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09554; Thu, 28 Feb 91 09:52:24 PST
Received: by  watnxt3.ucr.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA09538; Thu, 28 Feb 91 09:37:34 GMT-0800
X-NS-Transport-ID: 08002008D0FD00080193
In-Reply-to: "Stephen White's message of Wed, 27 Feb 1991 14:04:02 PST <9102272204.AA01035@watcgl.waterloo.edu>"
Message-ID: <9102281737.AA09538@watnxt3.ucr.edu>
Date:	Thu, 28 Feb 1991 09:37:34 PST
From:	rearl@watnxt2.ucr.edu (chup)
To:	MOO-Cows.PARC@xerox.com
Subject: Lack in New Locking System?

When I went to look at the @list code on Lambda, I was pretty
surprised to find out that code fragments were represented as strings
and not as lists of atoms of type code, or something like that.  One
of the ideas I had for MUCK 3.0 was, with the introduction of lists,
make it possible to fetch and store instructions to/from locations
just like variables, convert them into strings (like MOO's tostr()),
and execute code at arbitrary locations (with the proper checks :)

This would allow everything from self-modifying code (scary? you
decide!) to a symbolic debugger written in the language itself, and --
my favorite, runtime creation of new code, like lambda (no pun) in
Lisp or Scheme.

Now, MUF source and byte-code have a pretty much 1:1 relation between
the primitives you write and the actual code generated, so modifying
and examining the actual byte-code would make sense to the programmer,
but perhaps MOO code is a bit more complicated than that.

-- chupchup

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6099>; Thu, 28 Feb 1991 17:23:01 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16558>; Thu, 28 Feb 1991 14:06:51 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16584>; Thu, 28 Feb 1991 14:01:25 PST
Received: by watcgl.waterloo.edu
	id <AA08892>; Thu, 28 Feb 91 17:01:00 EST
X-NS-Transport-ID: 08002008D0FD000805D5
Message-ID: <9102282201.AA08892@watcgl.waterloo.edu>
Date:	Thu, 28 Feb 1991 14:01:00 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	MOO-Cows.PARC@xerox.com, rearl@watnxt2.ucr.edu
Subject: Re:  Lack in New Locking System?

a friendly chup says:
> When I went to look at the @list code on Lambda, I was pretty
> surprised to find out that code fragments were represented as strings
> and not as lists of atoms of type code, or something like that.  One
> of the ideas I had for MUCK 3.0 was, with the introduction of lists,
> make it possible to fetch and store instructions to/from locations
> just like variables, convert them into strings (like MOO's tostr()),
> and execute code at arbitrary locations (with the proper checks :)

code isn't represented internally as strings.  it's converted from
a list of strings to a parse tree when compiled, and vice versa
when @listed.  the reason that code is not is not a datatype
is that, as i mentioned before, the parse trees are not portable.

it would be possible to make byte-code level modifications if the
programs were stored as RPN tokens.  to be honest,  i don't see
the point.  how many C programmers do you know who debug by looking
at the assembly code produced by their compilers?

> This would allow everything from self-modifying code (scary? you
> decide!) to a symbolic debugger written in the language itself, and --
> my favorite, runtime creation of new code, like lambda (no pun) in
> Lisp or Scheme.

primitive (pardon the pun) runtime creation of new code is possible
with the compile() primitive.  i may try to write a simple boolean
expression -> MOO code translator for the tinymud emulation dbase,
for the hell of it.  then again, i may not.  :)

-- stephen/ghond

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <csc2.anu.edu.au!tja105>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6122>; Fri, 1 Mar 1991 18:12:31 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16145>; Fri, 1 Mar 1991 18:11:36 PST
Received: from csc2.anu.edu.au ([130.56.4.25]) by alpha.xerox.com with SMTP id <16145>; Fri, 1 Mar 1991 18:10:11 PST
Received: by csc2.anu.edu.au
	(5.61-bind 1.5+ida/IDA-1.2.8) id AA00431; Sat, 2 Mar 91 13:08:30 +1100
X-NS-Transport-ID: 08002008D0FD0008163F
Message-ID: <9103020208.AA00431@csc2.anu.edu.au>
Date:	Fri, 1 Mar 1991 18:08:30 PST
From:	tja105@csc2.anu.edu.au ("Timothy J Allen")
To:	MOO-Cows.PARC@xerox.com
Subject: Re: Locks and things

chupchup says:
>When I went to look at the @list code on Lambda, I was pretty
>surprised to find out that code fragments were represented as strings
>and not as lists of atoms of type code, or something like that.  One
>of the ideas I had for MUCK 3.0 was, with the introduction of lists,
>make it possible to fetch and store instructions to/from locations
>just like variables, convert them into strings (like MOO's tostr()),
>and execute code at arbitrary locations (with the proper checks :)
>
Depends how you look at it. I think of the verb_code() and set_verb_code()
primitives as converting code to and from lists of strings. How the server
wants to represent code is its business (you can tell I've never tried to
or wanted to hack a server, can't you? ;-)). What's the useful distinction
of a separate data type for code?

>This would allow everything from self-modifying code (scary? you
>decide!) to a symbolic debugger written in the language itself, and --
>my favorite, runtime creation of new code, like lambda (no pun) in
>Lisp or Scheme.

Actually, the pun was intended, though apparently not by you. At least,
that's what Lambda reckoned ages ago when someone (could have been me, can't
remember) asked him.

Self-modifying code? Scary? Nah! We (now reformed) MUSHers (used to) do it
all the time :) :).

enter ghond, stage left:
>
>code isn't represented internally as strings.  it's converted from
>a list of strings to a parse tree when compiled, and vice versa
>when @listed.  the reason that code is not is not a datatype
>is that, as i mentioned before, the parse trees are not portable.
>

This statement has always puzzled me somewhat. Especially since I looked
at how verb code is stored in the db; it's almost indistinguishable from
the text the user entered in the first place. So would someone mind explaining
to what extent moo code is 'compiled'? Obviously, it's checked for syntax
and stored somewhere, but is that compilation? Bear in mind that I am a
mere humble {;-)} physicist who is almost certainly unfamiliar with the
precise definitions of big words like 'compile'. It seems to me as though
moo code is, in effect, an interpreted language, but both ghond and
Lambda/Haakon have propounded this myth about it being compiled, so I
presume there is some point I'm not grasping here. Either that or there's
a conspiracy :).

>the point.  how many C programmers do you know who debug by looking
>at the assembly code produced by their compilers?

Isn't that in the 'Real programmers...' joke?

_______________________________________________________________________________
Tim Allen                                     tja105@csc2.anu.edu.au
Theoretical Physics
RSPhysS,ANU                     Don't woodchip the Lyman Alpha forest

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watnxt3.ucr.edu!rearl>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6103>; Fri, 1 Mar 1991 20:38:26 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16175>; Fri, 1 Mar 1991 20:38:00 PST
Received: from watnxt3.ucr.edu ([192.31.146.125]) by alpha.xerox.com with SMTP id <16175>; Fri, 1 Mar 1991 20:36:41 PST
Received: by  watnxt3.ucr.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA01682; Fri, 1 Mar 91 20:34:26 GMT-0800
X-NS-Transport-ID: 08002008D0FD0008171F
In-Reply-to: "\"Timothy J Allen\"'s message of Fri, 1 Mar 1991 18:08:30 PST <9103020208.AA00431@csc2.anu.edu.au>"
Message-ID: <9103020434.AA01682@watnxt3.ucr.edu>
Date:	Fri, 1 Mar 1991 20:34:26 PST
From:	rearl@watnxt3.ucr.edu (chup)
To:	MOO-Cows.PARC@xerox.com
Subject: Locks and things

|   [ .. ] What's the useful distinction
|   of a separate data type for code?

Let me rephrase what I said: instead of getting a list of strings
looking much like what you typed in, you would ask for a function's
code and you'd get a list of strings, integers, objects, and [the
theoretical] "primitive type"; meaning the keywords of the language
and builtin functions: "if", "notify()", "set_task_perms()".  You
would probably use tostr() to get a string name out of them.  More on
this later.

Changing the code becomes less kludgy, if not any more useful; if I
want to find an integer "3" in my code and make it a "4" I just locate
it and add one, instead of doing index() and concatenating new strings
together.

|   This statement has always puzzled me somewhat. Especially since I looked
|   at how verb code is stored in the db; it's almost indistinguishable from
|   the text the user entered in the first place. So would someone mind explaining
|   to what extent moo code is 'compiled'? Obviously, it's checked for syntax
|   and stored somewhere, but is that compilation? Bear in mind that I am a

byte-compilation.  MOO and MUF are both compiled and interpreted.
Hey, even BASIC was byte-compiled, I remember reading how each line
was scanned as you hit enter, and tokenized.  (eww)

Basically all the compiler does is nuke comments, parse things apart
at spaces, parentheses, and braces, and emit one or two bytes for
each builtin instruction.  So you get boxes like this (excuse the
muf):

[AND] [ADDR] [IF] [STRING] [VAR0] [@] [NOTIFY]
                    +---> "Allocated string space"

which is seven bytes, plus the string.  So it's smaller, you can
discard the original source code afterwards, or store it on disk.
Makes life a lot easier for the interpreter, which just does a lookup
based on primitive ID number.

MUF code is stored in a flat array, which is a pretty much 1:1
relation to what you typed in.  It has addresses coded in before if
and else statements to know where to jump after a test.  MOO code is
more of a tree, [quoting ghond] that allowed both traversal of the
trees for execution, and for "unparsing" back into source.

--chupchup

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!lamping>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6140>; Sat, 2 Mar 1991 17:16:26 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16248>; Sat, 2 Mar 1991 17:15:31 PST
Received: from owl.parc.xerox.com ([13.1.100.75]) by alpha.xerox.com with SMTP id <16248>; Sat, 2 Mar 1991 17:14:00 PST
Received: by owl.parc.xerox.com id <15362>; Sat, 2 Mar 1991 17:12:55 -0800
Fake-Sender: lamping@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD00081BB4
Message-ID: <91Mar2.171255pst.15362@owl.parc.xerox.com>
Date:	Sat, 2 Mar 1991 17:12:52 PST
From:	John Lamping <lamping@parc.xerox.com>
To:	MOO-Cows@parc.xerox.com
Subject: Another modest proposal

Talking with Pavel yesterday, he raised the subject of making property
access have more of the flexibility that verbs do.  So, for example, you
could put a guard on a property that only allowed it so be set to an
integer between 1 and 5, or you could put some code on a property access so
that it would return a context-dependent value.

The MOO already has some conventions that give this functionality in
special cases, for example, code is expected to call foo:description(),
rather than read foo.description.  The idea is to make these conventions
part of the system language.

I think that the principle of meta level access can provide some guidance.
Let me describe the principle, and then see how it suggests providing the
kinds of access described above.  Finally I'll argue that implementation
isn't difficult, and costs are reasonable.

I'm reluctant to use the word "meta", because it has been generalized to
the point of vacuousness, but here it is actually technically correct.  The
idea is to take some of the basic primitive operations of your language
(the trick is to pick the right ones) and pretend that they are implemented
by user code.  In particular make it so the user can write code that
changes how those operations are implemented.

The way you would do this in a MOO wouldis be to make it look to the user
that the primitive operations are implemented as verb calls.  For slot
access, you would say that foo.bar was implemented as the call
foo:bar_read(), and setting foo.bar to baz was implemented as
foo:bar_set(baz).  Of course the system doesn't actually implement them
that way, but it makes it look that way to the user by making it so that if
the user gives foo a verb with one of these names, then that verb will be
called, instead of doing the primitive operation.

Now, consider the guard mentioned above that is supposed to only allow the
value to be set to a number between 1 and 5.  It would be written as

.program foo:bar_set
value = args[1];
if (value >= 1 && value <= 5)
  pass(value);
endif
.

The code illustrates how the overriding verb does a pass(@args) if it want
to invoke the "real" primitive.  (It wouldn't work for this verb to do
foo.bar=value, because that is a setting of foo.bar, and would cause the
verb to be re-invoked, and so on forever.) The pass(@args) is also good for
a couple of other reasons.  First, it means that any guards further up the
inheritance hierarchy will also be called.  Second, it works well with the
protection system.  Since the guard verb isn't doing the set to the slot,
it doesn't need privileges for the slot; the slot doesn't have to belong to
the player who wrote the guard.

I can think of a couple other places in the MOO where this kind of access
looks good.  First, foo.bar is set, foo:bar_changed(new, old) should be
called.  It wouldn't be called if guards hadn't passed the change all the
way up to the primitive.  Second, after the create(...) function is called
to yield a new object, foo, foo:initialize() should be called.  The default
behavior of both of these verbs is to do nothing.

Implementing these facilities shouldn't be too expensive if the usual case
(where there are no user defined verbs) is marked and handled specially.
In particular, if there are no special verbs defined on a property, I would
store the value normally, while if there were special verbs defined, I
would store a special tag that told the system where to find the value, and
that it would have to look for the special verbs.

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <watcgl.waterloo.edu!sfwhite>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6142>; Sat, 2 Mar 1991 23:29:49 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16148>; Sat, 2 Mar 1991 23:28:57 PST
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16148>; Sat, 2 Mar 1991 23:27:27 PST
Received: by watcgl.waterloo.edu
	id <AA00895>; Sun, 3 Mar 91 02:25:21 EST
X-NS-Transport-ID: 08002008D0FD00081CC6
Message-ID: <9103030725.AA00895@watcgl.waterloo.edu>
Date:	Sat, 2 Mar 1991 23:25:21 PST
From:	Stephen White <sfwhite@watcgl.waterloo.edu>
To:	MOO-Cows.PARC@xerox.com, tja105@csc2.anu.edu.au
Subject: Re: Locks and things

i sez:
>> code isn't represented internally as strings.  it's converted from
>> a list of strings to a parse tree when compiled, and vice versa
>> when @listed.  the reason that code is not is not a datatype
>> is that, as i mentioned before, the parse trees are not portable.

gemba sez:
> This statement has always puzzled me somewhat. Especially since I looked
> at how verb code is stored in the db; it's almost indistinguishable from
> the text the user entered in the first place. So would someone mind explaining
> to what extent moo code is 'compiled'? [...]
> It seems to me as though
> moo code is, in effect, an interpreted language, but both ghond and
> Lambda/Haakon have propounded this myth about it being compiled, so I
> presume there is some point I'm not grasping here.

it's partly compiled, partly interpreted.  if it were fully
compiled, the server would be generating machine code from moo code,
which it doesn't do.  it instead compiles to an intermediate
representation, and later interpreted.

i'll try to explain basically how this works.   the yacc grammar
parses the language, and does all the dirty work of a parser (like
shifting & reducing tokens; don't worry if this doesn't mean
anything to you).  while it recognizes syntax, it also builds up a
bunch of pointers and data which represent the expressions.  so:

a = 2 + 2;

would become (in memory) something like:

	=
       / \
      a   +
	 / \
	2   2

where the '/' and '\'s are pointers, and the other stuff are
operators, strings, constants, what have you.  in order for the
interpreter to know what it's dealing with, it uses some constants
to say what the value at the end of a pointer is.  for example, '2'
would actually have an EXPR_NUM_CONST in front of it so the
interpreter knows what it is.

so, it's actually more like this:

	EXPR_ASGN
	    |
	ASGN_VAR
	/	\
       a     EXPR_PLUS
	        / \
  EXPR_NUM_CONST   EXPR_NUM_CONST
	|		 |
	2		 2


to unparse it into source, the unparser does an in-order traversal
of the tree, yielding a pretty-printed version of the source.  to
execute it, the interpreter does an in-order traversal, and evaluates
each primitive's arguments recursively.

so (for instance), seeing EXPR_ASGN, it recognizes that an
assignment is taking place.  seeing ASGN_VAR, it recognizes
that assignment to a variable is desired.  it follows the
left branch to determine which variable to assign to (an
index into the symbol table, but this is basically irrelevant).
it the evaulates the right branch (recursively) to determine
the value to assign.  EXPR_PLUS then evaluates _its_ arguments
recursively, yielding the numerical values 2 and 2 (all
values on the stack carry around their type with them).
EXPR_PLUS adds them, returns 4.  ASGN_VAR assigns it to
the variable a, and the expression is done.

keep in mind that this representation is strictly in-memory.  in the
db, it's stored unparsed.  this means that the server has to compile
all the verbs when the dbase is loaded.

>> the point.  how many C programmers do you know who debug by looking
>> at the assembly code produced by their compilers?

> Isn't that in the 'Real programmers...' joke?

if not, i suppose it should be.. :)

-- stephen

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6338>; Mon, 11 Mar 1991 16:41:54 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16983>; Mon, 11 Mar 1991 16:39:50 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16988>; Mon, 11 Mar 1991 16:37:17 PST
Received: by lambda.parc.xerox.com id <40705>; Mon, 11 Mar 1991 16:37:23 -0800
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Mon, 11 Mar 1991 16:37:20 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD000871FC
Message-ID: <Ibr2=0QB0KJLI1U=cP@lambda.parc.xerox.com>
Date:	Mon, 11 Mar 1991 16:37:20 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	MOO-Cows.PARC@xerox.com
Subject: New releases of LambdaMOO server and LambdaCore DB

 I've stored new releases of the LambdaMOO server code (now version
1.1.3) and the LambdaCore database.  The following changes were made to
the server since the last release:

-- Fixed benign unparsing bug that always parenthesized unary-minus
   expressions.
-- Changed move() to insert the newly-moved object as the last item in the
   contents list, rather than the first.
-- Fixed a less-than-benign bug in the unparsing of conditional expressions,
   where 'x ? y | (z ? w | v)' was being unparsed without the parentheses.
-- Fixed a bug whereby an extra checkpoint timer was created every time the
   '.dump' command was used.
-- Added printing the value of 'this' to error backtraces whenever it is
   different from the verb location.
-- Fixed bug in propogation of property ownership on object creation.

The changes to the core DB are numerous (and unrecorded) but include the
addition of the new locking system and the completion of the help
database.

	Pavel/Lambda/Haakon

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lucid.com!yduj>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6576>; Mon, 18 Mar 1991 14:23:58 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16955>; Mon, 18 Mar 1991 14:20:42 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <29059>; Mon, 18 Mar 1991 13:16:52 PST
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA08717g; Sun, 17 Mar 91 21:32:56 PST
Received: by boston-harbor id AA28812g; Mon, 18 Mar 91 00:38:12 EST
X-NS-Transport-ID: 08002008D0FD0008B235
Message-ID: <9103180538.AA28812@boston-harbor>
Date:	Sun, 17 Mar 1991 21:38:12 PST
From:	Judy Anderson <yduj@lucid.com>
To:	moo-cows.PARC@xerox.com
Subject: :name() verb

I am campaigning for a :name() verb to be called on an object in
$room:tell_contents and $player:look_self (when listing contents).  I
want to create an object which changes its name slightly whenever
someone sees it, but not necessarily in :description(), because nobody
will ever look at the object if it's in a player's possession (that's
too hard, you have to do ;#x.contents, and ;#y:look_self(), and
besides someone will bitch that it's not VR).  I would want it to work
similarly to :description().  Frand recommended that it go on #1, so
that players, rooms, and things alike can have changeable names.  What
do you all think?

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!pavel>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6604>; Mon, 18 Mar 1991 15:45:30 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16981>; Mon, 18 Mar 1991 15:23:27 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <28618>; Mon, 18 Mar 1991 15:02:50 PST
Received: by lambda.parc.xerox.com id <40705>; Mon, 18 Mar 1991 14:29:04 -0800
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.lambda.parc.xerox.com.sun4.40
          via MS.5.6.lambda.parc.xerox.com.sun4_40;
          Mon, 18 Mar 1991 14:28:50 -0800 (PST)
X-NS-Transport-ID: 08002008D0FD0008B820
In-Reply-to: <9103180538.AA28812@boston-harbor>
Message-ID: <MbtHwW8B0KJLA1U5tW@lambda.parc.xerox.com>
References: <9103180538.AA28812@boston-harbor>
Date:	Mon, 18 Mar 1991 14:28:50 PST
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	moo-cows.PARC@xerox.com
Subject: Re: :name() verb

I think that this is a fine suggestion, and easy to implement.

	Pavel

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <andrew.cmu.edu!ab46+>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6576>; Mon, 18 Mar 1991 16:03:01 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16252>; Mon, 18 Mar 1991 15:47:31 PST
Received: from andrew.cmu.edu ([128.2.11.131]) by alpha.xerox.com with SMTP id <16456>; Mon, 18 Mar 1991 15:17:25 PST
Received: by andrew.cmu.edu (5.54/3.15) id <AA22944> for moo-cows.PARC@xerox.com; Mon, 18 Mar 91 17:56:20 EST
Received: via switchmail; Mon, 18 Mar 91 17:56:17 -0500 (EST)
Received: from crippen.res.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.EbtIIwa00awGI0SXdG>;
          Mon, 18 Mar 91 17:54:53 -0500 (EST)
Received: from crippen.res.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr10/ab46/.Outgoing/QF.IbtIIt200awGE3xUk6>;
          Mon, 18 Mar 91 17:54:49 -0500 (EST)
Received: from BatMail.robin.v2.10.CUILIB.3.45.SNAP.NOT.LINKED.crippen.res.andrew.cmu.edu.pmax.30
          via MS.5.6.crippen.res.andrew.cmu.edu.pmax_30;
          Mon, 18 Mar 91 17:54:48 -0500 (EST)
Beak: is Not
X-NS-Transport-ID: 08002008D0FD0008B915
In-Reply-to: <9103180538.AA28812@boston-harbor>
Message-ID: <YbtIIsm00awGA3xUc6@andrew.cmu.edu>
References: <9103180538.AA28812@boston-harbor>
Date:	Mon, 18 Mar 1991 14:54:48 PST
From:	"Andrew F. Boardman" <ab46+@andrew.cmu.edu>
To:	moo-cows.PARC@xerox.com
Subject: Re: :name() verb


	A second!  I talked to G7 or Gemba about this a few days ago,
but never got around to posting anything about it.  :-)  :-)


					-- Satan

					--Andrew

Andrew F. Boardman :  ab46@andrew.cmu.edu
Carnegie-Mellon University  (Computer Science Major)
Raving Mad Lunatic Individualist, but Generally Nice

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com!lamping>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6580>; Mon, 18 Mar 1991 16:03:12 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16273>; Mon, 18 Mar 1991 15:51:42 PST
Received: from owl.parc.xerox.com ([13.1.100.75]) by alpha.xerox.com with SMTP id <16481>; Mon, 18 Mar 1991 15:17:40 PST
Received: by owl.parc.xerox.com id <15362>; Mon, 18 Mar 1991 14:55:31 -0800
Fake-Sender: lamping@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD0008B916
In-Reply-to: "Judy Anderson's message of Sun, 17 Mar 1991 21:38:12 PST <9103180538.AA28812@boston-harbor>"
Message-ID: <91Mar18.145531pst.15362@owl.parc.xerox.com>
Date:	Mon, 18 Mar 1991 14:55:29 PST
From:	John Lamping <lamping@parc.xerox.com>
To:	moo-cows.PARC@xerox.com
Subject: Re: :name() verb

I second Judy's (yduJ's?) suggestion with one modification: I would call
the verb something other than :name(), :maybe short_description().  The
reason is that I don't think that thing's names should change when the
intention is just to have their appearance change.  Since it is the
appearance that changes, I would have the name of the verb reflect that.

This proposal would certainly make thrown food much cleaner.



From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lucid.com!yduj>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6581>; Mon, 18 Mar 1991 16:36:07 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16254>; Mon, 18 Mar 1991 16:21:07 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16329>; Mon, 18 Mar 1991 16:17:12 PST
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA10502g; Mon, 18 Mar 91 16:13:42 PST
Received: by boston-harbor id AA00679g; Mon, 18 Mar 91 19:19:00 EST
X-NS-Transport-ID: 08002008D0FD0008BB0F
In-Reply-to: "John Lamping's message of Mon, 18 Mar 1991 14:55:29 PST <91Mar18.145531pst.15362@owl.parc.xerox.com>"
Message-ID: <9103190019.AA00679@boston-harbor>
Date:	Mon, 18 Mar 1991 16:19:00 PST
From:	Judy Anderson <yduj@lucid.com>
To:	lamping@parc.xerox.com
cc:	moo-cows.PARC@xerox.com
Subject: :name() verb

I like John's amendment to my proposal...    

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'

From someone sometime
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <hpb.cis.pitt.edu!hobbes>
Received: from alpha.xerox.com ([13.1.64.93]) by palain.parc.xerox.com with SMTP id <6574>; Mon, 18 Mar 1991 20:00:48 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16184>; Mon, 18 Mar 1991 19:50:28 PST
Received: from hpb.cis.pitt.edu ([130.49.6.51]) by alpha.xerox.com with SMTP id <16184>; Mon, 18 Mar 1991 19:48:07 PST
Received: by hpb.cis.pitt.edu (5.57/Ultrix2.4-C)
	id AA07105; Mon, 18 Mar 91 22:47:00 EST
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD0008BE22
Message-ID: <9103190347.AA07105@hpb.cis.pitt.edu>
Date:	Mon, 18 Mar 1991 19:46:58 PST
From:	hobbes@hpb.cis.pitt.edu (The Rain In Spain Falls Mainly On The Plane)
To:	moo-cows.PARC@xerox.com
Subject: Re: :name() verb

Well, quite bluntly, I don't see a use for it except for feeping
creatures to play with.  BUT I like feeping creatures, so...
I'm all for it, the more versatile the root object is, the less
space each sub object will take up...theoretically..:->
-- 
hobbes@hpb.cis.pitt.edu     | "My moral standing is lying down" - NIN
wbfst1@unix.cis.pitt.edu    | "I used to think that love was sensible" - IS
Tigger@zets (where's that?) | "What you say should be from your own mind!" - NE
It's very hard to have the east coast nuked and carry on a decent conversation.

From pavel@parc.xerox.com Wed Apr  3 13:31:12 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB14725; Wed, 3 Apr 91 13:31:11 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16350>; Wed, 3 Apr 1991 13:19:55 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16309>; Wed, 3 Apr 1991 13:14:09 PST
Received: by lambda.parc.xerox.com id <40706>; Wed, 3 Apr 1991 13:13:40 -0800
X-Ns-Transport-Id: 08002008D0FD00096C9D
Message-Id: <91Apr3.131340pst.40706@lambda.parc.xerox.com>
Date: 	Wed, 3 Apr 1991 13:13:30 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: Moo-Cows.PARC@xerox.com
Cc: Shawn Michael Carnell <smc8p@newton.acc.virginia.edu>
Subject: forwarded message from Shawn Michael Carnell

This was sent by mistake to MOO-Cows-Request, rather than MOO-Cows.  Shawn, I
have added you to MOO-Cows.

	Pavel/Lambda/Haakon

------- Start of forwarded message -------
Message-Id: <91Apr3.122203pst.16329@alpha.xerox.com>
Date: 	Wed, 3 Apr 1991 12:21:19 PST
From: Shawn Michael Carnell <smc8p@newton.acc.virginia.edu>
To: MOO-Cows-Request.PARC@xerox.com
Subject: Combat Systems

Hi,

I've been searching the M*** realm of the world to find a good
combat game (with experience/magic/levels/etc.) but keep running
into the same problem.  No games will let me maintain my
possessions when i log off.  Everthing i'm carrying gets dropped
where i stand.

Why is this?  It seems to be a symptom of LPMud's.  LambdaMOO is
actually the only game i know of which lets one keep one's niffy
stuff.  Having to sell everything and then buy it again at the
end and beginning of each session sort of soils the adventure.

Is there a way around this?  Can low level characters not keep
possessions?  Does anyone know of the kind of game i'm looking
for?

Any assistance would be most wonderful.

Thanks,
Shawn Carnell  -  smc8p@newton.acc.virginia.edu
------- End of forwarded message -------

From latour!mcr Wed Apr  3 17:16:57 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB15202; Wed, 3 Apr 91 17:16:56 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16340>; Wed, 3 Apr 1991 17:14:44 PST
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16266>; Wed, 3 Apr 1991 16:44:00 PST
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA21408; Wed, 3 Apr 91 19:43:23 EST
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA01619; Wed, 3 Apr 91 19:43:24 EST
Resent-Message-Id: <9104040043.AA01619@Sandelman.OCUnix.On.Ca>
Resent-From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Resent-Date: Wed, 3 Apr 1991 16:43:23 PST
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Resent-To: moo-cows@parc.xerox.com
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD00096F9C
Message-Id: <9104040043.AA01619@Sandelman.OCUnix.On.Ca>
Date: 	Tue, 2 Apr 1991 12:23:26 PST
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: moo@parc.xerox.com
Subject: Programmers's manual --- info format.

  I coverted the programmer's manual to info format (I may go all the way 
to texinfo soon).
  If someone wants, I can make arrangements to anon-ftp it somewhere. 
(I have to do that from school)
 
  :!mcr!:


From pavel@parc.xerox.com Wed Apr  3 17:59:19 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA15277; Wed, 3 Apr 91 17:59:18 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16332>; Wed, 3 Apr 1991 17:56:56 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16352>; Wed, 3 Apr 1991 17:33:00 PST
Received: by lambda.parc.xerox.com id <40706>; Wed, 3 Apr 1991 17:32:35 -0800
X-Ns-Transport-Id: 08002008D0FD0009702E
In-Reply-To: <9104040043.AA01619@Sandelman.OCUnix.On.Ca>
Message-Id: <91Apr3.173235pst.40706@lambda.parc.xerox.com>
Date: 	Wed, 3 Apr 1991 17:32:28 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows.PARC@xerox.com
Subject: Re: Programmers's manual --- info format.

Michael Richardson writes:
>   I coverted the programmer's manual to info format (I may go all the way 
> to texinfo soon).
>   If someone wants, I can make arrangements to anon-ftp it somewhere. 
> (I have to do that from school)
>  
>   :!mcr!:
> 

I am nearing completion of the second edition of the Programmer's Manual,
including complete descriptions of all built-in functions.  The new manual is
written in Texinfo and will be distributed in Texinfo, Postscript, and plain
text formats.  I anticipate being able to distribute an nroff/troff version as
well, but the conversion program 'texi2roff' has not yet been upgraded to deal
with the version of Texinfo I'm using.

	Pavel/Haakon/Lambda

From hofmann@sumter.cso.uiuc.edu Wed Apr  3 20:23:44 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <hofmann@sumter.cso.uiuc.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA15387; Wed, 3 Apr 91 20:23:43 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16339>; Wed, 3 Apr 1991 20:22:00 PST
Received: from sumter.cso.uiuc.edu ([128.174.43.2]) by alpha.xerox.com with SMTP id <16339>; Wed, 3 Apr 1991 20:18:40 PST
Received: by sumter.cso.uiuc.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
	id AA11254; Wed, 3 Apr 91 22:17:12 GMT-0600
X-Ns-Transport-Id: 08002008D0FD000971B8
Message-Id: <9104040417.AA11254@sumter.cso.uiuc.edu>
Date: 	Wed, 3 Apr 1991 20:17:12 PST
From: hofmann@sumter.cso.uiuc.edu (J. Scott Hofmann)
To: moo-cows@parc.xerox.com

>Cc: Shawn Michael Carnell <smc8p@newton.acc.virginia.edu>
>
>I've been searching the M*** realm of the world to find a good
>combat game (with experience/magic/levels/etc.) but keep running
>into the same problem.  No games will let me maintain my
>possessions when i log off.  Everthing i'm carrying gets dropped
>where i stand.
>
>Is there a way around this?  Can low level characters not keep
>possessions?  Does anyone know of the kind of game i'm looking
>for?
>
>Shawn Carnell  -  smc8p@newton.acc.virginia.edu

   Shawn, There is a new type of mud out of Denmark called the DikuMUD which
lets you rent space in inns in which to store your stuff, so you don't lose
it. The game is very similar to LPMud, with many extensions. There are
presently about 4 DikuMUDS online in the US, and 1 in Sweden (I think).
I publish a mud list, available from belch.berkeley.edu's anon ftp directory
/pub/muds/mud_misc with all the address. I'll mail you a copy. 

                                                -Scott Hofmann
                                         hofmann@sumter.cso.uiuc.edu




From cerebus@ucscb.ucsc.edu Wed Apr  3 20:43:24 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cerebus@ucscb.ucsc.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA15398; Wed, 3 Apr 91 20:43:24 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16368>; Wed, 3 Apr 1991 20:42:03 PST
Received: from ucscb.UCSC.EDU ([128.114.129.6]) by alpha.xerox.com with SMTP id <16373>; Wed, 3 Apr 1991 20:38:44 PST
Received: by ucscb.UCSC.EDU (5.65/1.34)
	id AA25789; Wed, 3 Apr 91 20:38:02 -0800
X-Ns-Transport-Id: 08002008D0FD000971E9
Message-Id: <9104040438.AA25789@ucscb.UCSC.EDU>
Date: 	Wed, 3 Apr 1991 20:38:02 PST
From: cerebus@ucscb.ucsc.edu (Austintatious Aardvark)
To: hofmann@sumter.cso.uiuc.edu, moo-cows@parc.xerox.com
Subject: RE: Losing stuff on muds


>Cc: Shawn Michael Carnell <smc8p@newton.acc.virginia.edu>
>
>I've been searching the M*** realm of the world to find a good
>combat game (with experience/magic/levels/etc.) but keep running
>into the same problem.  No games will let me maintain my
>possessions when i log off.  Everthing i'm carrying gets dropped
>where i stand.
>
>Is there a way around this?  Can low level characters not keep
>possessions?  Does anyone know of the kind of game i'm looking
>for?
>
>Shawn Carnell  -  smc8p@newton.acc.virginia.edu

   Shawn, There is a new type of mud out of Denmark called the DikuMUD which
lets you rent space in inns in which to store your stuff, so you don't lose
it. The game is very similar to LPMud, with many extensions. There are
presently about 4 DikuMUDS online in the US, and 1 in Sweden (I think).
I publish a mud list, available from belch.berkeley.edu's anon ftp directory
/pub/muds/mud_misc with all the address. I'll mail you a copy. 

                                                -Scott Hofmann
                                         hofmann@sumter.cso.uiuc.edu




	On SCOmud here in Santa Cruz, there are lockers you can label
and lock with a password.  If you're interested in the code, you could
probably get it from falcon@gorn.santa-cruz.ca

						-Jame Scholl
					cerebus@ucscb.ucsc.edu

From latour!mcr Fri Apr  5 22:22:27 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA19224; Fri, 5 Apr 91 22:22:26 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16204>; Fri, 5 Apr 1991 22:17:02 PST
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16204>; Fri, 5 Apr 1991 22:15:00 PST
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA17468; Sat, 6 Apr 91 01:14:16 EST
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA24760; Sat, 6 Apr 91 01:05:32 EST
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD00098E9B
Message-Id: <9104060605.AA24760@Sandelman.OCUnix.On.Ca>
Date: 	Fri, 5 Apr 1991 22:05:30 PST
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: moo-cows@parc.xerox.com
Subject: Sub-classes of container.

  I have a feeling that what I want to do isn't going to work too well due to a location
field that can only have a unique value, but...

  I want to have a container type where all its sub-instances have the
same contents as the parent. In particular, if I add something to the
parent, I want it to appear in the sub-instance too. 
  (Don't ask me what I'm doing. Needless to say, it ISN'T very
orthodox at all)
  Is the code for the core of lambda available for ftp somewhere? I
don't think I saw it wherever it was that I got the lamdba sources
from. I'm going to go and check now.

  (BTW: Unless people are really clamoring for the info version of the
ProgrammersManual, I'm going to wait for Lamdba to finish his.)


-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!



From pavel@parc.xerox.com Fri Apr  5 22:37:33 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA19243; Fri, 5 Apr 91 22:37:32 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16233>; Fri, 5 Apr 1991 22:36:34 PST
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16229>; Fri, 5 Apr 1991 22:35:16 PST
Received: by lambda.parc.xerox.com id <40706>; Fri, 5 Apr 1991 22:34:56 -0800
X-Ns-Transport-Id: 08002008D0FD00098EB1
In-Reply-To: <9104060605.AA24760@Sandelman.OCUnix.On.Ca>
Message-Id: <91Apr5.223456pst.40706@lambda.parc.xerox.com>
Date: 	Fri, 5 Apr 1991 22:34:41 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: mcr@sandelman.ocunix.on.ca
Cc: moo-cows@parc.xerox.com
Subject: Re: Sub-classes of container.

The source code for the core of the LambdaMOO database is available from
[belch.berkeley.edu]pub/moo/LambdaMOO/LambdaCore-*.db.  I believe that the most
recent version there is dated 11-Mar-91.

	Pavel/Lambda/Haakon

From latour!mcr Tue Apr  9 21:56:31 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA28472; Tue, 9 Apr 91 21:56:30 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16294>; Tue, 9 Apr 1991 21:50:31 PDT
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16196>; Tue, 9 Apr 1991 21:47:23 PDT
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA24343; Wed, 10 Apr 91 00:46:03 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA04709; Wed, 10 Apr 91 00:46:14 EDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD0009B2FC
Message-Id: <9104100446.AA04709@Sandelman.OCUnix.On.Ca>
Date: 	Tue, 9 Apr 1991 21:46:13 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: moo-cows@parc.xerox.com
Subject: pass()

  Does pass() (as in pass(@args)) invoke the same method on the 'super class'?
  If not what does it do?
  How does one invoke the super method?


From latour!mcr Wed Apr 10 09:16:07 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB28995; Wed, 10 Apr 91 09:16:06 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16301>; Wed, 10 Apr 1991 09:12:25 PDT
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16138>; Wed, 10 Apr 1991 09:06:37 PDT
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA29459; Wed, 10 Apr 91 12:05:16 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA04963; Wed, 10 Apr 91 01:37:12 EDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD0009B89C
Message-Id: <9104100537.AA04963@Sandelman.OCUnix.On.Ca>
Date: 	Tue, 9 Apr 1991 22:37:11 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: moo-cows@parc.xerox.com
Subject: More questions.

  [ Is it appropriate for me to post small questions to this list? I notice
from the archives that most of the topics discussed are more intimately 
related to design of the system rather than 'average' programming. ]
  
  I want to have a piece of equipement (an Atomic Vector Plotter comes to
mind, but I'm not doing an HHGG world) that has a cable connected to it.
  I have neat things like cables, when you look at them they tell you if
they are connected to anything, and to what. If both ends are loose, they
say so. (I will eventually put plugs on the ends. No plugging DB25s into
AC outlets now...) 
  What I want to be able to do is have the cable ATTACHED to the thing I plug
it into, yet still have it visible at the same level of thing. When you
pick up a thing with a cable attached to it, you get the cable too. If the
other end is attached to something, MAYBE you get that thing (haven't 
decided yet. Whatevever the case, you can't leave the room and dangle 
cables. [Unless the cable is long enough, but I'm not going to that yet]) too.

  Right now, I have all my things a sub-class of container (named 'component')
Components can be 'copy'ed. Copying a component recursively copies all the 
'parts' too. (Some of which may be named and actually reside in specific 
properties. [I like to call them slots, a la Self])
  How to copy a whole sub-system and keep all the copies of the cables 
connected to the copies of the parts, I have ideas about, but haven't 
implemented yet. 

  Boy do I like MOO :-) Thanks.


From pavel@parc.xerox.com Wed Apr 10 10:39:33 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB29123; Wed, 10 Apr 91 10:39:32 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16821>; Wed, 10 Apr 1991 10:36:25 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16855>; Wed, 10 Apr 1991 10:30:24 PDT
Received: by lambda.parc.xerox.com id <40706>; Wed, 10 Apr 1991 10:29:02 -0700
X-Ns-Transport-Id: 08002008D0FD0009B9E5
In-Reply-To: <9104100446.AA04709@Sandelman.OCUnix.On.Ca>
Message-Id: <91Apr10.102902pdt.40706@lambda.parc.xerox.com>
Date: 	Wed, 10 Apr 1991 10:28:52 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: mcr@sandelman.ocunix.on.ca
Cc: moo-cows@parc.xerox.com
Subject: Re: pass()

Michael Richardson writes:
>   Does pass() (as in pass(@args)) invoke the same method on the
>   'super class'?  If not what does it do?  How does one invoke the super
>   method?

Yes, it does what you think it does.  Here's the documentation on pass() from
the next version of the programmer's manual (due to be released this week):


 * Function: pass (ARG, ...)
     Often, it is useful for a child object to define a verb that *augments*
     the behavior of a verb on its parent object.  For example, in the
     LambdaCore database, the root object (which is an ancestor of every
     other object) defines a verb called `description' that simply returns
     the value of `this.description'; this verb is used by the
     implementation of the `look' command.  In many cases, a programmer
     would like the description of some object to include some
     non-constant part; for example, a sentence about whether or not the
     object was `awake' or `sleeping'.  This sentence should be added onto
     the end of the normal description.  The programmer would like to have
     a means of calling the normal `description' verb and then appending
     the sentence onto the end of that description.  The function `pass()'
     is for exactly such situations.

     `pass' calls the verb with the same name as the current verb but as
     defined on the parent of the object that defines the current verb. 
     The arguments given to `pass' are the ones given to the called verb
     and the returned value of the called verb is returned from the call to
     `pass'.  The value of `this' in the called verb is the same as in the
     calling verb.

     Thus, in the example above, the child-object's `description' verb might
     have the following implementation:

          return pass() + "  It is " + (this.awake ? "awake." | "sleeping.");

     That is, it calls its parent's `description' verb and then appends to
     the result a sentence whose content is computed based on the value of a
     property on the object.

	Haakon

From pavel@parc.xerox.com Wed Apr 10 10:58:47 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB29173; Wed, 10 Apr 91 10:58:45 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16841>; Wed, 10 Apr 1991 10:56:25 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16448>; Wed, 10 Apr 1991 10:35:34 PDT
Received: by lambda.parc.xerox.com id <40706>; Wed, 10 Apr 1991 10:33:13 -0700
X-Ns-Transport-Id: 08002008D0FD0009B9F5
In-Reply-To: <9104100537.AA04963@Sandelman.OCUnix.On.Ca>
Message-Id: <91Apr10.103313pdt.40706@lambda.parc.xerox.com>
Date: 	Wed, 10 Apr 1991 10:33:11 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: mcr@sandelman.ocunix.on.ca
Cc: moo-cows@parc.xerox.com
Subject: Re: More questions.

Michael Richardson writes:
>   [ Is it appropriate for me to post small questions to this list? I notice
> from the archives that most of the topics discussed are more intimately 
> related to design of the system rather than 'average' programming. ]

Yes, it is definitely appropriate to use the list for the kinds of questions
you've been asking.

>   I want to have a piece of equipement (an Atomic Vector Plotter comes to
> mind, but I'm not doing an HHGG world) that has a cable connected to it.
>   I have neat things like cables, when you look at them they tell you if
> they are connected to anything, and to what. If both ends are loose, they
> say so. (I will eventually put plugs on the ends. No plugging DB25s into
> AC outlets now...) 
>   What I want to be able to do is have the cable ATTACHED to the thing I plug
> it into, yet still have it visible at the same level of thing. When you
> pick up a thing with a cable attached to it, you get the cable too. If the
> other end is attached to something, MAYBE you get that thing (haven't 
> decided yet. Whatevever the case, you can't leave the room and dangle 
> cables. [Unless the cable is long enough, but I'm not going to that yet])
> too.

The first thing that occurs to me is to make the :moveto verbs on each of the
attached objects move the other objects in that attached group as well.  (Be
careful not to get into an infinite recursion, though...)

>  Right now, I have all my things a sub-class of container (named 'component')
> Components can be 'copy'ed. Copying a component recursively copies all the 
> 'parts' too. (Some of which may be named and actually reside in specific 
> properties. [I like to call them slots, a la Self])
>   How to copy a whole sub-system and keep all the copies of the cables 
> connected to the copies of the parts, I have ideas about, but haven't 
> implemented yet.

Doing all this copying doesn't sound like a good thing in general, since it
will use up your quota at a furious pace...

>   Boy do I like MOO :-) Thanks.

You're welcome.

	Haakon

From lamping@parc.xerox.com Wed Apr 10 11:13:34 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@parc.xerox.com>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB29193; Wed, 10 Apr 91 11:13:32 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16876>; Wed, 10 Apr 1991 11:11:25 PDT
Received: from owl.parc.xerox.com ([13.1.100.75]) by alpha.xerox.com with SMTP id <16455>; Wed, 10 Apr 1991 10:54:18 PDT
Received: by owl.parc.xerox.com id <15362>; Wed, 10 Apr 1991 10:51:32 -0700
Fake-Sender: lamping@parc.xerox.com
X-Ns-Transport-Id: 08002008D0FD0009BA48
In-Reply-To: "Michael Richardson's message of Tue, 9 Apr 1991 22:37:11 PDT <9104100537.AA04963@Sandelman.OCUnix.On.Ca>"
Message-Id: <91Apr10.105132pdt.15362@owl.parc.xerox.com>
Date: 	Wed, 10 Apr 1991 10:51:28 PDT
From: John Lamping <lamping@parc.xerox.com>
To: moo-cows@parc.xerox.com
Cc: mcr@sandelman.ocunix.on.ca
Subject: Containers (was More questions.)

I think that it is appropriate to post all kinds of questions to this list.

Anyway, I think that containment and attachment are two different notions.
Containment is about what is present in the environment (what you see when
you look, etc.), while attachment is about what else moves when you move
something.  So containment is a special case of attachment: when I move a
container, I move everything in it.

Now the LambdaMOO kernel doesn't make this distinction.  It even makes it
kind of difficult to make the distinction, because the .location property
determines both what you see and what else moves when you move something.

But if you view the kernel as implementing the containment special case of
attachment, then you can add what you want.  Rather than using containment
for your, more general, kind of attachment, make a new kind of $thing, an
attachable thing.  Attachable things have a property that lists all the
things that they are directly attached to, and there is a verb to attach
two things together (which asks the things if they are willing to be
attached, so that they can check plug compatibility, etc.).  Finally, a
:moveto operation on an attached thing moves everything it is attached to
(and everything those things are attached to ...).  If something is
(transitively) attached to the current room, then you can't pick it up,
because you can't pick up the room.

A variation would be that when you picked up an attached thing, you didn't
get what it was attached to (if, say, the attached thing was a flexible
object), but if you left the room, the things you took with you would
become detached from things you left behind.  This would, I think, require
adding code to the default :exitfunc to check for this situation.


From latour!mcr Wed Apr 10 20:47:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA00313; Wed, 10 Apr 91 20:47:28 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16976>; Wed, 10 Apr 1991 20:36:39 PDT
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16977>; Wed, 10 Apr 1991 20:34:33 PDT
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA16350; Wed, 10 Apr 91 23:27:45 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA07076; Wed, 10 Apr 91 22:14:54 EDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD0009C187
In-Reply-To: "Pavel Curtis <pavel@parc.xerox.com>
       \"Re: More questions.\" (Apr 10, 10:33am)----"
Message-Id: <9104110214.AA07076@Sandelman.OCUnix.On.Ca>
Date: 	Wed, 10 Apr 1991 19:14:53 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: Pavel Curtis <pavel@parc.xerox.com>
Cc: moo-cows@parc.xerox.com
Subject: Re: More questions.

On Apr 10, 10:33am, Pavel Curtis wrote:
} The first thing that occurs to me is to make the :moveto verbs on each of the
} attached objects move the other objects in that attached group as well.  (Be
} careful not to get into an infinite recursion, though...)
  
  But the OTHER end of the cable may still be attached to something
else. In particular, it might be attached to the wall! 
  If I started putting plugs on the cables (such that an 'end' was an
object) do you think this will help at all?

} >   How to copy a whole sub-system and keep all the copies of the cables 
} > connected to the copies of the parts, I have ideas about, but haven't 
} > implemented yet.
} 
} Doing all this copying doesn't sound like a good thing in general, since it
} will use up your quota at a furious pace...

  This isn't a problem as this is running on my machine, and I've set
up MOO for the purpose of doing this. I'm the Wizard most of the time.
  See, I'm modelling reality.
  MUD's are virtual realities, [gee, why am I telling you this?] and
I've come to realise are much easier for building models of real-life
things in than anything else I've come across. 





From pavel@parc.xerox.com Thu Apr 11 17:53:21 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA01784; Thu, 11 Apr 91 17:53:20 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16156>; Thu, 11 Apr 1991 17:49:23 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16147>; Thu, 11 Apr 1991 17:46:17 PDT
Received: by lambda.parc.xerox.com id <40706>; Thu, 11 Apr 1991 17:45:59 -0700
X-Ns-Transport-Id: 08002008D0FD0009CD31
Message-Id: <91Apr11.174559pdt.40706@lambda.parc.xerox.com>
Date: 	Thu, 11 Apr 1991 17:45:52 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: New manual and server version 1.2.0 released

I just copied to belch.berkeley.edu, in the directory pub/moo/LambdaMOO/, the
following items:

-- ProgrammersManual.texinfo, ProgrammersManual.ps, ProgrammersManual.ps.Z:
  The new version of the programmer's manual for LambdaMOO.  This version
includes full documentation of all 61 built-in functions.  The Texinfo version
is human-readable and will have to do until the program that converts Texinfo
into plain text is made less buggy by its creator.  The Postscript versions
(including an uncompressed one for folks who can't uncompress things but do
have a Postscript printer) are reasonably pretty, if I do say so myself; much
more readable than the old plain-text version.  Thanks are due to Gus for doing
the initial conversion from plain-text into Texinfo.

-- LambdaMOO-1.2.0.tar.Z:
  The latest version of the server code.  Many small bug fixes are included and
some minor improvements in several functions.  Look for the next released
version to include support for suspending tasks and reading lines of input from
the player.  Also, the next version may well support a standalone configuration
that doesn't require a network, so that folks can have a private, single-player
MOO on which to experiment.

-- LambdaCore-11Apr91.db:
  A freshly-extracted copy of the core of LambdaMOO.  New in this version is a
line-oriented program editor, for use by folks who don't have a better
solution.

	Pavel/Haakon/Lambda

From lamping@parc.xerox.com Mon Apr 15 09:59:48 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05654; Mon, 15 Apr 91 09:59:47 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16205>; Mon, 15 Apr 1991 09:51:48 PDT
Received: from owl.parc.xerox.com ([13.1.100.75]) by alpha.xerox.com with SMTP id <16240>; Mon, 15 Apr 1991 09:27:58 PDT
Received: by owl.parc.xerox.com id <15362>; Mon, 15 Apr 1991 09:25:47 -0700
Fake-Sender: lamping@parc.xerox.com
X-Ns-Transport-Id: 08002008D0FD0009E86C
Message-Id: <91Apr15.092547pdt.15362@owl.parc.xerox.com>
Date: 	Mon, 15 Apr 1991 09:25:36 PDT
From: John Lamping <lamping@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: A suggestion about key expressions

   I think that key expressions are overspecialized.  Specifically, you
don't always want the key expression to check all the objects that
something hereditarily contains.  (I suspect that the current state is a
result of keys having originally been for determining what is allowed in a
room.)

   Suppose that you want to have an object that a player can't get rid of.
Then the obvious thing to do would seem to be to lock it to the player.
But, as Morpheus discovered, that doesn't work: the player tries to put the
object down; the lock is checked against the room the player is in, which
contains the player, so the lock succeeds.

   Off the top of my head, I can think of three kinds of checks that you might
want to do on an object:
   1. Is it a particular object (what you want for the case above)
   2. Does is hereditarily contain a particular object (the current case)
   3. Is it a descendant of a particular object (to check for types)

   It seems like key expressions ought to support all three cases.  I would
even argue that case (1) ought to be the normal case, with the other two
specially marked with, say, contains(x) or descendent(x).

   As usual, if asked to do any of the work, the author will disavow any
knowledge of these ideas.  This message should self-destruct in 5 seconds.
Good luck.

From crew@neon.stanford.edu Thu Apr 18 14:20:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB12620; Thu, 18 Apr 91 14:20:53 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16285>; Thu, 18 Apr 1991 14:17:40 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <16134>; Thu, 18 Apr 1991 04:25:26 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA07031; Thu, 18 Apr 91 04:22:58 -0700
X-Ns-Transport-Id: 08002008D0FD000A10B5
Message-Id: <9104181122.AA07031@Neon.Stanford.EDU>
Date: 	Thu, 18 Apr 1991 04:22:53 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@parc.xerox.com
Subject: verb/property permissions

I was doing a bit of thinking about the way verb permissions and such 
*should* work and figured I'd spew it at the readership (mainly to 
Haakon, since he's most likely got something planned anyway...)

First, some anomalies in the current state of affairs:

(*) We have the notion of making an object unreadable so that you
    can't find out what verbs are available.  All well and good, yet
    if you should manage to find out the name of a verb (say, by
    having someone show you a @listing of something that calls it),
    you can now call it yourself.  Perhaps the verb owner has
    remembered to put in security checks, but perhaps not.  This
    situation persists until the owner renames the verb and makes
    unreadable every piece of code that refers to the verb...  <antisocial>

(*) If you want to know whether a verb is readable, you can call verb_info().
    The catch is that verb_info() barfs with an E_PERM if the verb isn't
    readable.  As it happens, you can extract most of the information
    verb_info() would have provided by noting whether the error msg is 
    E_PERM or E_VERBNF.

(*) The object 'r' flag is overloaded, it controls both readability 
    of props/verbs, and usability as a parent.
    There are at least a few situations where one wants to rule out 
    children for an otherwise entirely readable object (e.g., consider
    the possibility of forging mail by creating children of the mailroom, 
    though this can be fixed by changing certain 'this' references to 
    explicit object numbers [yuk!!]).  There are also situations where 
    the parent might want to have some private verbs kept to itself out 
    of reach of the children...

For verbs, I'd identify 4 permissions, though, as we'll see, not all of 
these need to be actual flags:

  'e' === listed,    i.e., being able to know that the verb exists.  
  'r' === readable, as in, being able to determine what a verb does.  
  'x' === callable from a program, i.e., recognized in an 'obj:(...)' context.
  'i' === callable from (i.e., recognized on) the command line.
  (we won't talk about 'd')

Naturally, the verb owner can do anything, so these serve only to
limit what others can do.  'r', 'x' and 'i' are basically
independent, but all entail 'e', that is, you shouldn't be able to do
anything with a verb unless you have some legitimate means of knowing
that it exists.  The converse also holds; there is no point to having
a verb listed if you can't do anything with it (*) 
So, basically 'e' == 'r'||'x'||'i' and we don't really need an 
explicit 'e' flag after all.

Likewise, rather than create a new 'i' flag, we just note 'i' really means

  verb_args(...) != {this,none,this}

and punt on the possibility of people having private command-line
verbs (!i && verb_args != {this,none,this}).
What this means though is that verb_args(...) should have the same
availability as verb_info(...).  There's no harm in this since
verb_args() really provides no clue as to what the verb actually does
(any more than does the player 'exam' command).
The 'r' permission then affects only verb_code(...).

Putting it all together, we get, for non-owners

  verbs(obj)
     returns a list of all verbs on obj that *either*
     have 'r' set, have 'x' set, or have args != {this,none,this}.
     obj.r is ignored completely.

     (*) N.B. When called by obj.owner, verbs(obj) should list *all*
      of obj's verbs, even those owned by someone else that are
      !r!x&this-none-this, since even if you can't do anything with
      them, their presence affects whether you can remove them or add
      other verbs with the same names.

  verb_info(obj,"verb")
  verb_args(obj,"verb")
     returns info iff the caller knows the verb to exist 
                     (i.e., verb would have been listed by 'verbs(obj)')
     otherwise ==> E_VERBNF  (not E_PERM!!!)

  verb_code(obj,"verb")
     returns code iff 'r' is set on that verb, 
     elseif caller knows verb to exist ==>  E_PERM,
     otherwise ==> E_VERBNF.

  set_verb_*(...)
     ==> E_PERM/E_VERBNF according as caller knows the verb to exist, 
     as above.  I would suggest doing away with the verb 'w' flag completely.
     [N.B. If you absolutely must have a 'w' flag for verbs
       make it so that writing on a verb changes its ownership, 
       otherwise the 'w' flag is totally useless, since if you
       create a 'w' verb, anybody can write to it and make you do 
       anything they want.]

Some other consequences:

  (*) Since 'x' now only affects what others can do with your verbs,
      your own !x verbs *will* be recognized inside your other verbs.
      (I believe this is what G7 was arguing for...).

  (*) 'this none this' verbs that are !x and !r disappear completely 
      from public view.

  (*) If a verb obj:foo() is !x, and the obj has a child, any verbs on the 
      child owned by someone other from (obj:foo).owner will not be able 
      to call this:foo() unless either the child defines its own :foo() 
      or some ancestor of obj defines a :foo() that is x'able.
      (note that parent verbs not owned by (obj:foo).owner suffer the same 
      restriction -- so far, so good).  This doesn't actually
      introduce any new restrictions since, at present, you can't call an
      !x verb at all.

      Now, if the child *does* have its own :foo() not owned by 
      (obj:foo).owner, any calls to pass() that child:foo() makes will 
      ignore obj:foo() and search parent(obj)&ancestors for a runnable 
      :foo().

      The key idea here is that since obj:foo is !x, it is unrecognized 
      by anything not owned by (obj:foo).owner

Default permissions should be rx(d) for 'this none this' verbs and 
r(d) for any other choice of args (though rx(d) can't hurt....)

For properties, I can't be quite as specific, since I don't know
enough about the new permission scheme proposed to replace the 
current 'c' flag.  However the basic idea is the same:

'properties(obj)' will list "prop" and
'property_info(obj,"prop")' will return actual info rather than E_PROPNF iff

  (*) the caller owns the property, or 
  (*) the property's permissions are such that the caller can do 
      something with it (i.e., 'r' or 'w'), or
  (*) the caller owns 'obj'.


Object flags:
  'r' is now a fertility flag (stands for 'reproduction' instead of 'read'),
   !r == only the owner can chparent (his) things to this object

  'w': controls adding/removing properties and verbs, as before...


From dxb105@phys.anu.edu.au Thu Apr 18 23:02:19 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dxb105@phys.anu.edu.au>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13413; Thu, 18 Apr 91 23:02:18 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16242>; Thu, 18 Apr 1991 22:59:38 PDT
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <16242>; Thu, 18 Apr 1991 22:55:44 PDT
Received: from PHYS.DECnet MAIL11D_V3 by anu.anu.edu.au (5.57/1.0)
	id AA04003; Fri, 19 Apr 91 15:09:56 EST
Posted-Date: Fri, 19 Apr 91 15:09:54 EST
X-Ns-Transport-Id: 08002008D0FD000A1C36
Message-Id: <9104190509.AA04003@anu.anu.edu.au>
Date: 	Fri, 19 Apr 1991 13:09:54 PDT
From: dxb105@phys.anu.edu.au (David Bofinger)
To: mc@anu.anu.edu.au
Cc: DXB105@anu.anu.edu.au
Subject: Permissions

Roger Crew <crew@neon.stanford.edu> has been:

>[...] doing a bit of thinking about the way verb permissions and such 
>*should* work and figured I'd spew it at the readership (mainly to 
>Haakon, since he's most likely got something planned anyway...)

Yes, he has. It's not clear what priority it has, though, I hear that Haakon's
whiteboard is pretty full. Roger writes lots of good stuff, so I'll leave the
bouquets to Haakon and just toss some very minor carping criticisms in.

>     (*) N.B. When called by obj.owner, verbs(obj) should list *all*
>      of obj's verbs, even those owned by someone else that are
>      !r!x&this-none-this, since even if you can't do anything with
>      them, their presence affects whether you can remove them or add
>      other verbs with the same names.

Is this true? You certainly can have two verbs of the same name, it's even of
practical value (though also a horrid kludge) if they have differing args. More
importantly, by giving these special privileges to the owners of the children,
you've essentially reunified your verb-detecting permissions with the r flag on
the object. Want to know about a verb, just make a child and examine that.

> I would suggest doing away with the verb 'w' flag completely.
If it existed, so would I. VERY DANGEROUS.

>     [N.B. If you absolutely must have a 'w' flag for verbs
>       make it so that writing on a verb changes its ownership, 
>       otherwise the 'w' flag is totally useless, since if you
>       create a 'w' verb, anybody can write to it and make you do 
>       anything they want.]

Exactly. The sort of flag that makes wizards wake up at three oclock in the
morning in a cold sweat. How can you sound so _calm_ about it? :-)
Incidentally, you keep neglecting wizards in your permissions discussion,
presumably they can do anything they like, a reasonable approximation but I
thought I'd mention it exists.

On a peripheral note, Most other MUDs do provide facilities for the transfer of
ownership of objects. Now transferring verbs is just too dangerous in my
opinion, but I think property ownership transfer is perfectly legit, and we
should have a mechanism for it. Object transfer is slightly dubious, it
obviously should require the new owner's permission, whereas properties don't
(as clearly). Comments are solicited.

>  (*) Since 'x' now only affects what others can do with your verbs,
>      your own !x verbs *will* be recognized inside your other verbs.
>      (I believe this is what G7 was arguing for...).

Your cheque (in 7G$) is in the mail.

>      Now, if the child *does* have its own :foo() not owned by 
>      (obj:foo).owner, any calls to pass() that child:foo() makes will 
>      ignore obj:foo() and search parent(obj)&ancestors for a runnable 
>      :foo().

I suppose so, and certainly consistent with present day LambdaPolicy. Strangely
disturbing, though...

>Default permissions should be rx(d) for 'this none this' verbs and 
>r(d) for any other choice of args (though rx(d) can't hurt....)

I vote yes for d.

>'properties(obj)' will list "prop" and
>'property_info(obj,"prop")' will return actual info rather than E_PROPNF iff
> [...]
>  (*) the caller owns 'obj'.

Same thought as verbs, I guess. For instance, should players be told there is a
"password" verb on them? I can't see why...

>Object flags:
>   !r == only the owner can chparent (his) things to this object

What if the object is a descendant anyway, and wants to be a child? What if
it's a grandchild, and its parent is recycled? Imagine if I have a single child
of your !r object. I can create children of it, then recycle it. Now I have as
many children as I want. I'd be inclined to permit people to reattach
objects higher up a parenting tree.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
		MOO: Gary_Severn, Dukas, 7G et al
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"In the beginning there was the word, and the word was Aardvark." - Cerebrus

From lamping@parc.xerox.com Fri Apr 19 10:36:35 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14279; Fri, 19 Apr 91 10:36:34 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16333>; Fri, 19 Apr 1991 10:33:54 PDT
Received: from navarro.parc.xerox.com ([13.2.18.19]) by alpha.xerox.com with SMTP id <16300>; Fri, 19 Apr 1991 10:26:47 PDT
Received: by navarro.parc.xerox.com id <36097>; Fri, 19 Apr 1991 10:27:12 -0700
Fake-Sender: lamping@parc.xerox.com
X-Ns-Transport-Id: 08002008D0FD000A22A9
In-Reply-To: "David Bofinger's message of Fri, 19 Apr 1991 13:09:54 PDT <9104190509.AA04003@anu.anu.edu.au>"
Message-Id: <91Apr19.102712pdt.36097@navarro.parc.xerox.com>
Date: 	Fri, 19 Apr 1991 10:27:06 PDT
From: John Lamping <lamping@parc.xerox.com>
To: Moo-cows@parc.xerox.com
Subject: Re: Permissions

>>      Now, if the child *does* have its own :foo() not owned by 
>>      (obj:foo).owner, any calls to pass() that child:foo() makes will 
>>      ignore obj:foo() and search parent(obj)&ancestors for a runnable 
>>      :foo().
>
>I suppose so, and certainly consistent with present day LambdaPolicy. Strangely
>disturbing, though...

I think this is a mistake in an otherwise excellent suggestion.  It is
conflating two different issues: protection vs name spaces.  The 'x' bit is
about protection.  Setting or clearing the 'x' bit should affect whether
errors are produced, but should not alter the results of a successful
computation (unless it catches errors ... that's different).  So just as an
attempt to call a verb you don't have permissions to run should result in
an error (not an attempt to find a verb higher up the hierarchy that you do
have permissions for ... how does it work now?), an attempt to pass() to a
verb you don't have execute permissions for should result in an error.

There is one other possibility consistent with the above criterion: if your
caller had permissions to call the verb you do the pass() to, and you do a
pass(@args), sending up the original args, then it is  legal, and the
caller that the verb sees should probably be your caller, not you.  This
would allow people to insert checks and do other auxiliary things, but I'm
not sure I like it.



From ken@imsa.edu Fri Apr 19 12:46:11 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA16452; Fri, 19 Apr 91 12:46:10 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16472>; Fri, 19 Apr 1991 12:43:41 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <16479>; Fri, 19 Apr 1991 12:35:33 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA10908; Fri, 19 Apr 91 13:48:20 CDT
X-Ns-Transport-Id: 08002008D0FD000A25B0
Message-Id: <9104191848.AA10908@imsa.edu>
Date: 	Fri, 19 Apr 1991 11:48:20 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: Moo-cows@parc.xerox.com
Subject: Re:  Permissions

dxb105@phys.anu.edu.au (David Bofinger) writes:

>[...] You certainly can have two verbs of the same name, it's even of
>practical value (though also a horrid kludge) if they have differing args.

    I don't find it to ba all that of an unsavory way of doing things.
Although I have no idea how this works internally (where it may be
rather ineloquent), it gives one the ability to do something like
C++'s function overloading, which is a most nifty feature.  (Put the
OO back in MOO :-)

    If a serious re-vamping of permissions is going on, it might be
worth while to look over the UberMUD documentation, as it does a very
good job of handling permissions.  Although it doesn't deal with any
OOP stuff, it has good explanations and justifications and a generally
well-worked-out permission structure.  (For one thing, it says that
being able to read and call a function should be the same thing, as
being able to read it implies being able to execute it, as code is
really just data, but that's another debate altogether.)

    Going back to C++, has anyone thought of doing permissions that
work like making fields and methods (C++ terminology here) private?
Sort of like a 'self' set of permissions?  If you don't know what I'm
talking about, let me explain.  Imagine if you could make a property
so that it could only be read or written by verbs attached to the same
object as it is attached to?  This may seem a bit silly at first, but
it can solve many problems related to people and code, which isn't
supposed to, over-writing data.  (For a better explanation of why this
is neat, read 'The C++ Programming language' by Bjarne Stoustrup, or
any other decent text on C++.)  I think it might be a handy thing to
have in MOO, although I'd be the last one to pile work on poor Haakon
:-)

//////////////////////////////////////////////////////////////////////
\ Kenneth C Schalk \\\"Is conciousness just a special form of \\\\\\\\  //-\
//////////////////////  hallucination?"--Frank Herbert        //////// //-O|
\ ken@imsa.edu \\\\\\\"We're each other fragments...but each        \\ |   |
/ schalk@mcs.anl.gov / fragment reveals the rose from a different   //  \_/
\ k-schalk@uiuc.edu \\ angle..."-- William Gibson                   \\
//////////////////////////////////////////////////////////////////////

(aka Xorian in MOOs)

From crew@neon.stanford.edu Sat Apr 20 04:40:34 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA18167; Sat, 20 Apr 91 04:40:32 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16266>; Sat, 20 Apr 1991 04:38:46 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <16266>; Sat, 20 Apr 1991 04:36:41 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA05839; Sat, 20 Apr 91 04:34:19 -0700
X-Date: Thu, 18 Apr 91 23:26:50 PST
X-Ns-Transport-Id: 08002008D0FD000A2E9D
In-Reply-To: "Your message of Fri, 19 Apr 91 13:09:54 -0700.
             <9104190509.AA04003@anu.anu.edu.au>"
Message-Id: <9104201134.AA05839@Neon.Stanford.EDU>
Date: 	Sat, 20 Apr 1991 04:34:14 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@parc.xerox.com
Subject: Re: Permissions

>>  I would suggest doing away with the verb 'w' flag completely.
>  If it existed, so would I. VERY DANGEROUS.

The programmers manual claims such a beast exists, 
but I've been too afraid to try it out.

 ------------
>>   'properties(obj)' will list "prop" and
>>   'property_info(obj,"prop")' will return actual info rather than E_PROPNF 
>>    iff
>>    [...]
>>     (*) the caller owns 'obj'.
>   
>   Same thought as verbs, I guess. For instance, should players be told there
>   is a "password" [property] on them? I can't see why...

add_property() and remove_property() both fail if the property is defined on 
an ancestor.  So the object owner is at least entitled to know that these 
properties exist.

 ------------
>>   Object flags:
>>      !r == only the owner can chparent (his) things to this object
   
>   What if the object is a descendant anyway, and wants to be a child? What if
>   it's a grandchild, and its parent is recycled? Imagine if I have a single
>   child of your !r object. I can create children of it, then recycle it. Now
>   I have as many children as I want. I'd be inclined to permit people to
>   reattach objects higher up a parenting tree.

Consider the situation where object A has a dangerous verb :rmstar(),
let's assume the danger lies in being able to call it as this:rmstar()
I create B, a child of A, give it an innocuous :rmstar() and then
deem it safe for people to derive children from B.  A's :rmstar() can
still be called by pass()ing from B's, but B:rmstar() can puts in
tests to make it safe.  In this situation, I wouldn't want any
children of B to reparent themselves to A.

The intended interpretation of the proposed object .r flag is

  TRUE:   I'll let people create instances of this.
  FALSE:  I think that children of this object have the potential to 
          screw me over, therefore, only *I* can have children of this object

This means that if I do 'obj.r = 0' then any children that don't
belong to me get reparented to the first ancestor which still is
eligible (this may be different for each child), becoming siblings or
even great*-uncles in process.  This automatically takes care of
grandchildren, whether or not they belong to me; presumably, if I care
about keeping some of these grandchildren as children of obj, 
I would chparent them first before reseting the .r flag.

If this seems to be requiring a lot to happen on the mere setting of a 
property, keep in mind that .r isn't a real property any more than is, say,
.wizard is ...  In any case I suspect that changing a .r to 0 would be a rare 
occurrence (caused by someone waking up at 3am in a cold sweat and panicking).

>>        (*) N.B. When called by obj.owner, verbs(obj) should list *all*
>>         of obj's verbs, even those owned by someone else that are
>>         !r!x&this-none-this, since even if you can't do anything with
>>         them, their presence affects whether you can remove them or add
>>         other verbs with the same names.

>   Is this true? You certainly can have two verbs of the same name,
>   it's even of practical value (though also a horrid kludge) if they
>   have differing args. 
>...
>   More importantly, by giving these special privileges to the owners
>   of the children, you've essentially reunified your verb-detecting
>   permissions with the r flag on the object. Want to know about a
>   verb, just make a child and examine that.

2nd point first:
No, because verbs()/verb_info()/verb_args() only report on verbs that are 
actually defined on the object; examining a child will not reveal any 
information about inherited verbs.

As for having having two (noninherited) verbs with the same name on
the same object, if it really is intended to allow people to have 
multiple @args possibilities for a given verbname, it currently doesn't 
work.  Experimental evidence suggests that if the more recent verb's name 
subsumes (i.e., matches all of the same names as) the previous one, then
there's no way to get at the previous verb, whether to call it, list it
or .program it.  This holds even if the args are different; the parser
gives up after finding the first matching verb and then moves on to
the parent object as far as I can tell.

The question of the right way to fix this is a thorny one, but a
distinct subject from permissions, so I'll save it for now.

 - - - - - - - - - - - - -
Re: UberMUD:
> ... being able to read and call a function should be the same thing,

NO!

My own prejudice is that everyone should be able to *read* every verb
(i.e., aside from verbs dealing with the particulars of puzzles and 
adventuring scenarios, which should be unreadable so as not to spoil the fun),
so that they can find out how it all works, have examples of programming style
(:-) and all that good stuff.  Suffice it to say that calling permissions 
should be a bit more restricted.  

>   Going back to C++, has anyone thought of doing permissions that
>   work like making fields and methods (C++ terminology here) private?
>   Sort of like a 'self' set of permissions?

This is the point behind having (!r!c) properties and
(!x)&&(this-none-this) verbs on an object that is .r==1.  
In some sense this is much like to C++'s notion of "private"
field/method in the case that the child and parent have different owners
or "protected" field/method in the case that the child and parent share 
the same owner.

--
Roger Crew                                        ``I kill Optimax...''
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MUD:       Rog

From crew@neon.stanford.edu Sat Apr 20 04:46:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA18176; Sat, 20 Apr 91 04:46:39 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16269>; Sat, 20 Apr 1991 04:45:16 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <16294>; Sat, 20 Apr 1991 04:43:14 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA05973; Sat, 20 Apr 91 04:40:51 -0700
X-Date: Thu, 18 Apr 91 23:26:50 PST
X-Ns-Transport-Id: 08002008D0FD000A2EA7
In-Reply-To: "Your message of Fri, 19 Apr 1991 10:27:06 PDT
             <91Apr19.102712pdt.36097@navarro.parc.xerox.com>"
Message-Id: <9104201140.AA05973@Neon.Stanford.EDU>
Date: 	Sat, 20 Apr 1991 04:40:46 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@parc.xerox.com
Subject: Re: Permissions

>>>      Now, if the child *does* have its own :foo() not owned by 
>>>      (obj:foo).owner, any calls to pass() that child:foo() makes will 
>>>      ignore obj:foo() and search parent(obj)&ancestors for a runnable 
>>>      :foo().

>>  I suppose so, and certainly consistent with present day LambdaPolicy. 
>>  Strangely disturbing, though...

>  I think this is a mistake in an otherwise excellent suggestion.  It is
>  conflating two different issues: protection vs name spaces.  The 'x' bit is
>  about protection.

In fact, now that I think about it, the 'x' bit really is about name spaces, 
even though I made the mistake of calling it a permission bit before.  
Specifically, it's about search paths; !x means it's entirely out of 
a non-owner's path when he's making a call from a program.
So in your sense it isn't a protection bit at all, even though it provides the
most comprehensive protection imaginable by virtue of removing the offending
verb from view.  If you want to do protection in the more usual sense of having
someone be able to try calling your verb only to get 'Permission Denied', then
it is still possible, if slightly cumbersome, to do

  if (caller_perms()!=<me>) 
    return E_PERM; 
  endif

at the beginning of the verb body (I assume that the new error handling
system in the works allows a way of doing "raise E_PERM" instead of
"return E_PERM", but that's a whole other discussion).  However,
unless the goal is to block access to a parent verb, !x will suffice.

Now, the 'r' bit *is* a genuine permission bit, needed because properties and
verb code have no control over who reads them the way verb bodies can control
who runs them.  I'd prefer to be economical about flags, i.e., have them only 
handle things that can't otherwise be done from within the verb code.

One further clarification is that 'r' should have nothing to do with
execution search paths, so that an attempt to call an (r && !x) verb
should result in E_VERBNF even though the verb is known to exist via 
verbs()/verb_info().  This is actually the present state of affairs; 
in the proposed scheme this would only happen to non-owners.

What's really happening in the disturbing example above is that obj has this
private verb :foo() that, by coincidence, shares the same name as a public verb
available on some ancestor.  Why give it that name?  Maybe because obj's owner
was stupid and forgot that there was such a public verb; I don't know.  
The point though is that the presence or absence of such a private verb, 
whatever its name, should not affect the interface seen by the outside world.
In particular, not even the children need to know about it --- if they think 
the verb they're calling lives on the grandparent, that's the verb they 
should get.  They shouldn't start getting permission denied for no apparent 
reason.  If you actually do need to have a parent verb intervening then it 
should have 'x' set.

The confusion is that protection and name spaces are not orthogonal issues.
If something is not in the name space, then it's completely protected by 
virtue of being inaccessible.  Conversely, providing permission for 
something implicitly puts it in the name space (or should, anyway).
In this way '!x' can, paradoxically, provide protection while, likewise,
'r' can sometimes extend the name space (e.g., for verbs()/verb_info()/
verb_args()...)

--
Roger Crew                                        ``I kill Optimax...''
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MOO:       Rog

From crew@neon.stanford.edu Sat Apr 20 04:40:34 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA18167; Sat, 20 Apr 91 04:40:32 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16266>; Sat, 20 Apr 1991 04:38:46 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <16266>; Sat, 20 Apr 1991 04:36:41 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA05839; Sat, 20 Apr 91 04:34:19 -0700
X-Date: Thu, 18 Apr 91 23:26:50 PST
X-Ns-Transport-Id: 08002008D0FD000A2E9D
In-Reply-To: "Your message of Fri, 19 Apr 91 13:09:54 -0700.
             <9104190509.AA04003@anu.anu.edu.au>"
Message-Id: <9104201134.AA05839@Neon.Stanford.EDU>
Date: 	Sat, 20 Apr 1991 04:34:14 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@parc.xerox.com
Subject: Re: Permissions

>>  I would suggest doing away with the verb 'w' flag completely.
>  If it existed, so would I. VERY DANGEROUS.

The programmers manual claims such a beast exists, 
but I've been too afraid to try it out.

 ------------
>>   'properties(obj)' will list "prop" and
>>   'property_info(obj,"prop")' will return actual info rather than E_PROPNF 
>>    iff
>>    [...]
>>     (*) the caller owns 'obj'.
>   
>   Same thought as verbs, I guess. For instance, should players be told there
>   is a "password" [property] on them? I can't see why...

add_property() and remove_property() both fail if the property is defined on 
an ancestor.  So the object owner is at least entitled to know that these 
properties exist.

 ------------
>>   Object flags:
>>      !r == only the owner can chparent (his) things to this object
   
>   What if the object is a descendant anyway, and wants to be a child? What if
>   it's a grandchild, and its parent is recycled? Imagine if I have a single
>   child of your !r object. I can create children of it, then recycle it. Now
>   I have as many children as I want. I'd be inclined to permit people to
>   reattach objects higher up a parenting tree.

Consider the situation where object A has a dangerous verb :rmstar(),
let's assume the danger lies in being able to call it as this:rmstar()
I create B, a child of A, give it an innocuous :rmstar() and then
deem it safe for people to derive children from B.  A's :rmstar() can
still be called by pass()ing from B's, but B:rmstar() can puts in
tests to make it safe.  In this situation, I wouldn't want any
children of B to reparent themselves to A.

The intended interpretation of the proposed object .r flag is

  TRUE:   I'll let people create instances of this.
  FALSE:  I think that children of this object have the potential to 
          screw me over, therefore, only *I* can have children of this object

This means that if I do 'obj.r = 0' then any children that don't
belong to me get reparented to the first ancestor which still is
eligible (this may be different for each child), becoming siblings or
even great*-uncles in process.  This automatically takes care of
grandchildren, whether or not they belong to me; presumably, if I care
about keeping some of these grandchildren as children of obj, 
I would chparent them first before reseting the .r flag.

If this seems to be requiring a lot to happen on the mere setting of a 
property, keep in mind that .r isn't a real property any more than is, say,
.wizard is ...  In any case I suspect that changing a .r to 0 would be a rare 
occurrence (caused by someone waking up at 3am in a cold sweat and panicking).

>>        (*) N.B. When called by obj.owner, verbs(obj) should list *all*
>>         of obj's verbs, even those owned by someone else that are
>>         !r!x&this-none-this, since even if you can't do anything with
>>         them, their presence affects whether you can remove them or add
>>         other verbs with the same names.

>   Is this true? You certainly can have two verbs of the same name,
>   it's even of practical value (though also a horrid kludge) if they
>   have differing args. 
>...
>   More importantly, by giving these special privileges to the owners
>   of the children, you've essentially reunified your verb-detecting
>   permissions with the r flag on the object. Want to know about a
>   verb, just make a child and examine that.

2nd point first:
No, because verbs()/verb_info()/verb_args() only report on verbs that are 
actually defined on the object; examining a child will not reveal any 
information about inherited verbs.

As for having having two (noninherited) verbs with the same name on
the same object, if it really is intended to allow people to have 
multiple @args possibilities for a given verbname, it currently doesn't 
work.  Experimental evidence suggests that if the more recent verb's name 
subsumes (i.e., matches all of the same names as) the previous one, then
there's no way to get at the previous verb, whether to call it, list it
or .program it.  This holds even if the args are different; the parser
gives up after finding the first matching verb and then moves on to
the parent object as far as I can tell.

The question of the right way to fix this is a thorny one, but a
distinct subject from permissions, so I'll save it for now.

 - - - - - - - - - - - - -
Re: UberMUD:
> ... being able to read and call a function should be the same thing,

NO!

My own prejudice is that everyone should be able to *read* every verb
(i.e., aside from verbs dealing with the particulars of puzzles and 
adventuring scenarios, which should be unreadable so as not to spoil the fun),
so that they can find out how it all works, have examples of programming style
(:-) and all that good stuff.  Suffice it to say that calling permissions 
should be a bit more restricted.  

>   Going back to C++, has anyone thought of doing permissions that
>   work like making fields and methods (C++ terminology here) private?
>   Sort of like a 'self' set of permissions?

This is the point behind having (!r!c) properties and
(!x)&&(this-none-this) verbs on an object that is .r==1.  
In some sense this is much like to C++'s notion of "private"
field/method in the case that the child and parent have different owners
or "protected" field/method in the case that the child and parent share 
the same owner.

--
Roger Crew                                        ``I kill Optimax...''
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MUD:       Rog

From crew@neon.stanford.edu Sat Apr 20 04:46:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA18176; Sat, 20 Apr 91 04:46:39 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16269>; Sat, 20 Apr 1991 04:45:16 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <16294>; Sat, 20 Apr 1991 04:43:14 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA05973; Sat, 20 Apr 91 04:40:51 -0700
X-Date: Thu, 18 Apr 91 23:26:50 PST
X-Ns-Transport-Id: 08002008D0FD000A2EA7
In-Reply-To: "Your message of Fri, 19 Apr 1991 10:27:06 PDT
             <91Apr19.102712pdt.36097@navarro.parc.xerox.com>"
Message-Id: <9104201140.AA05973@Neon.Stanford.EDU>
Date: 	Sat, 20 Apr 1991 04:40:46 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@parc.xerox.com
Subject: Re: Permissions

>>>      Now, if the child *does* have its own :foo() not owned by 
>>>      (obj:foo).owner, any calls to pass() that child:foo() makes will 
>>>      ignore obj:foo() and search parent(obj)&ancestors for a runnable 
>>>      :foo().

>>  I suppose so, and certainly consistent with present day LambdaPolicy. 
>>  Strangely disturbing, though...

>  I think this is a mistake in an otherwise excellent suggestion.  It is
>  conflating two different issues: protection vs name spaces.  The 'x' bit is
>  about protection.

In fact, now that I think about it, the 'x' bit really is about name spaces, 
even though I made the mistake of calling it a permission bit before.  
Specifically, it's about search paths; !x means it's entirely out of 
a non-owner's path when he's making a call from a program.
So in your sense it isn't a protection bit at all, even though it provides the
most comprehensive protection imaginable by virtue of removing the offending
verb from view.  If you want to do protection in the more usual sense of having
someone be able to try calling your verb only to get 'Permission Denied', then
it is still possible, if slightly cumbersome, to do

  if (caller_perms()!=<me>) 
    return E_PERM; 
  endif

at the beginning of the verb body (I assume that the new error handling
system in the works allows a way of doing "raise E_PERM" instead of
"return E_PERM", but that's a whole other discussion).  However,
unless the goal is to block access to a parent verb, !x will suffice.

Now, the 'r' bit *is* a genuine permission bit, needed because properties and
verb code have no control over who reads them the way verb bodies can control
who runs them.  I'd prefer to be economical about flags, i.e., have them only 
handle things that can't otherwise be done from within the verb code.

One further clarification is that 'r' should have nothing to do with
execution search paths, so that an attempt to call an (r && !x) verb
should result in E_VERBNF even though the verb is known to exist via 
verbs()/verb_info().  This is actually the present state of affairs; 
in the proposed scheme this would only happen to non-owners.

What's really happening in the disturbing example above is that obj has this
private verb :foo() that, by coincidence, shares the same name as a public verb
available on some ancestor.  Why give it that name?  Maybe because obj's owner
was stupid and forgot that there was such a public verb; I don't know.  
The point though is that the presence or absence of such a private verb, 
whatever its name, should not affect the interface seen by the outside world.
In particular, not even the children need to know about it --- if they think 
the verb they're calling lives on the grandparent, that's the verb they 
should get.  They shouldn't start getting permission denied for no apparent 
reason.  If you actually do need to have a parent verb intervening then it 
should have 'x' set.

The confusion is that protection and name spaces are not orthogonal issues.
If something is not in the name space, then it's completely protected by 
virtue of being inaccessible.  Conversely, providing permission for 
something implicitly puts it in the name space (or should, anyway).
In this way '!x' can, paradoxically, provide protection while, likewise,
'r' can sometimes extend the name space (e.g., for verbs()/verb_info()/
verb_args()...)

--
Roger Crew                                        ``I kill Optimax...''
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MOO:       Rog

From sfwhite@watcgl.waterloo.edu Sat Apr 20 16:22:54 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA18631; Sat, 20 Apr 91 16:22:53 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16514>; Sat, 20 Apr 1991 16:20:14 PDT
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16506>; Sat, 20 Apr 1991 16:18:02 PDT
Received: by watcgl.waterloo.edu
	id <AA10869>; Sat, 20 Apr 91 19:17:21 EDT
X-Ns-Transport-Id: 08002008D0FD000A30F7
Message-Id: <9104202317.AA10869@watcgl.waterloo.edu>
Date: 	Sat, 20 Apr 1991 16:17:21 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: Moo-cows@parc.xerox.com, ken@imsa.edu
Subject: Re:  Permissions

the other reason that 'r' permission on code elements in Uber handles
execution permissions is that Uber does not keep source code, or
allow you to "unparse" it.

-- stephen

From sfwhite@watcgl.waterloo.edu Sat Apr 20 16:33:31 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA18644; Sat, 20 Apr 91 16:33:30 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16407>; Sat, 20 Apr 1991 16:31:53 PDT
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16407>; Sat, 20 Apr 1991 16:30:05 PDT
Received: by watcgl.waterloo.edu
	id <AA11321>; Sat, 20 Apr 91 19:29:20 EDT
X-Ns-Transport-Id: 08002008D0FD000A3111
Message-Id: <9104202329.AA11321@watcgl.waterloo.edu>
Date: 	Sat, 20 Apr 1991 16:29:20 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: crew@neon.stanford.edu, moo-cows@parc.xerox.com
Subject: Re: Permissions

> The intended interpretation of the proposed object .r flag is
> 
>   TRUE:   I'll let people create instances of this.
>   FALSE:  I think that children of this object have the potential to 
>           screw me over, therefore, only *I* can have children of this object

another way to do this is to restrict create() or instantiate() or
whatever it's called (i can't even remember-- sad, eh?) to the object
itself, or one of its parents.  you would have to "ask" an object to
instantiate itself.  doing away with permissions altogether is not
a bad idea.

>> Re: UberMUD:
>> ... being able to read and call a function should be the same thing,

> NO!

> My own prejudice is that everyone should be able to *read* every verb
> (i.e., aside from verbs dealing with the particulars of puzzles and 
> adventuring scenarios, which should be unreadable so as not to spoil the fun),
> so that they can find out how it all works, have examples of programming style
> (:-) and all that good stuff.  Suffice it to say that calling permissions 
> should be a bit more restricted.  

that was how it was meant to be in the Good Old Days.  things seemed to
have gotten clouded over in the meanwhile.

-- stephen/ghond

From latour!mcr Sun Apr 21 22:55:43 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA20036; Sun, 21 Apr 91 22:55:42 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16668>; Sun, 21 Apr 1991 22:53:50 PDT
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16668>; Sun, 21 Apr 1991 22:51:49 PDT
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA22286; Mon, 22 Apr 91 01:49:20 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA09293; Mon, 22 Apr 91 01:38:30 EDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD000A36B3
Message-Id: <9104220538.AA09293@Sandelman.OCUnix.On.Ca>
Date: 	Sun, 21 Apr 1991 22:38:28 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: moo-cows@parc.xerox.com
Subject: New ProgrammersManual

  I just ran makeinfo on it, but there is no Top node, and there doesn't seem
to be any menu structure at all in the file.  Was this intentional, i.e. no 
menu structure has been done yet, or...?
  I'm going to post my info file to belch.


From pavel@parc.xerox.com Mon Apr 22 09:51:14 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA20749; Mon, 22 Apr 91 09:51:13 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16176>; Mon, 22 Apr 1991 09:45:36 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16171>; Mon, 22 Apr 1991 09:42:17 PDT
Received: by lambda.parc.xerox.com id <40706>; Mon, 22 Apr 1991 09:42:00 -0700
X-Ns-Transport-Id: 08002008D0FD000A3AC2
In-Reply-To: <9104220538.AA09293@Sandelman.OCUnix.On.Ca>
Message-Id: <91Apr22.094200pdt.40706@lambda.parc.xerox.com>
Date: 	Mon, 22 Apr 1991 09:41:45 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: mcr@sandelman.ocunix.on.ca
Cc: MOO-Cows.PARC@xerox.com
Subject: Re: New ProgrammersManual

>   I just ran makeinfo on it, but there is no Top node, and there doesn't seem
> to be any menu structure at all in the file.  Was this intentional, i.e. no 
> menu structure has been done yet, or...?

Yes.  My intent was to make a plain-text file, not an Info file, since many
users of the MOO cannot make use of Info files.

What version of makeinfo did you use?  I had lots of trouble (strange line
breaks) with versions 2.00 through 2.03.

	Pavel/Haakon

From lamping@parc.xerox.com Mon Apr 22 10:04:23 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA20778; Mon, 22 Apr 91 10:04:22 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16175>; Mon, 22 Apr 1991 10:02:59 PDT
Received: from navarro.parc.xerox.com ([13.2.18.19]) by alpha.xerox.com with SMTP id <16171>; Mon, 22 Apr 1991 09:59:59 PDT
Received: by navarro.parc.xerox.com id <36097>; Mon, 22 Apr 1991 10:00:56 -0700
Fake-Sender: lamping@parc.xerox.com
X-Ns-Transport-Id: 08002008D0FD000A3AF3
Message-Id: <91Apr22.100056pdt.36097@navarro.parc.xerox.com>
Date: 	Mon, 22 Apr 1991 10:00:41 PDT
From: John Lamping <lamping@parc.xerox.com>
To: MOO-COWS@parc.xerox.com
Subject: Namespaces (was Re: Permissions)

> In fact, now that I think about it, the 'x' bit really is about name spaces, 
> even though I made the mistake of calling it a permission bit before.  
> Specifically, it's about search paths; !x means it's entirely out of 
> a non-owner's path when he's making a call from a program.

I think that the 'x' bit is a bad way to make namespaces, because it
doesn't complete the job, and because what is in your namespace is tied to
your permissions.  This can lead to some very counterintuitive behavior.

Suppose, for example, that Rog makes some nice object and magnanimously
grants others the ability to read his code and make instances of his
object, but reserves the right to execute some of the verbs to himself.
Now Aladdin comes along, likes Rog's object, but, of course, wants to make
some minor changes.  So he reads Rogs's code, makes his own instance, and
redefines one of the verbs on his instance.  When Aladdin tries out his new
masterpiece it doesn't behave anything like Rog's object, because when
Aladdin's verb tries to call the verbs that Rog defined, they are bypassed,
because they are not in Aladdin's execution namespace, notwithstanding that
Aladdin just listed them.

Poor Aladdin has been hit by two problems of the 'x' bit as a namespace.
First, the namespace is only apparent during execution, not at other times,
so you are not aware of it until it is too late.  Second, the namespace is
defined relative to permissions, instead of being something that you can
explicitly control.  This means that wizards don't get namespaces; any
wizard code sees everything mushed together.

Now, having namespaces in the MOO might be a good thing, so that it is
possible to make libraries of useful verbs, for example.  The $... syntax
provides some of this, but only gives wizard controlled namespaces (that
is, only wizards can add definitions).  Player controlled namespaces would
also be good, but, like the current wizard namespaces, they should have to
be explicitly referred to, so that code is portable from player to player.
Also, there needs to be some way to inhibit the creation of lots of player
controlled namespaces that duplicate functionality.  That seems to be the
hard part, for which I have no good ideas.

From mcr@doe.carleton.ca Mon Apr 22 14:37:24 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <mcr@doe.carleton.ca>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21658; Mon, 22 Apr 91 14:37:23 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16232>; Mon, 22 Apr 1991 14:35:42 PDT
Received: from doe.carleton.ca ([134.117.11.32]) by alpha.xerox.com with SMTP id <16229>; Mon, 22 Apr 1991 14:30:38 PDT
Received: by doe.carleton.ca (4.0/SMI-4.0)
	id AA13808; Mon, 22 Apr 91 17:26:23 EDT
X-Ns-Transport-Id: 08002008D0FD000A3F1D
Message-Id: <9104222126.AA13808@doe.carleton.ca>
Date: 	Mon, 22 Apr 1991 14:26:23 PDT
From: mcr@doe.carleton.ca (Michael Richardson)
To: moo-cows@parc.xerox.com
Subject: My Prog manual.

  The (Emacs) info version of the 1.0 ProgrammersManual is in /pub/moo/mcr_ProgMan.info 
on belch.berkeley.edu.

  I'll probably add menus to the 1.2 version soon.


From pavel@parc.xerox.com Mon Apr 22 14:59:52 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21713; Mon, 22 Apr 91 14:59:51 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16232>; Mon, 22 Apr 1991 14:58:12 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16229>; Mon, 22 Apr 1991 14:53:25 PDT
Received: by lambda.parc.xerox.com id <40706>; Mon, 22 Apr 1991 14:53:07 -0700
X-Ns-Transport-Id: 08002008D0FD000A3F76
Message-Id: <91Apr22.145307pdt.40706@lambda.parc.xerox.com>
Date: 	Mon, 22 Apr 1991 14:52:55 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: MOO-Cows archives

A more-or-less complete archive of all MOO-Cows mail for the year so far can be
found on arisia.xerox.com in the file pub/MOO-Cows-1991.txt in UNIX-standard
mail format.  Non-UNIX-using folks can read it easily; it's just plain ASCII
text.

	Pavel

From ken@imsa.edu Fri Apr 26 08:51:58 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA02137; Fri, 26 Apr 91 08:51:57 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16152>; Fri, 26 Apr 1991 08:49:54 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <16152>; Fri, 26 Apr 1991 08:47:43 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA00620; Fri, 26 Apr 91 10:46:02 CDT
X-Ns-Transport-Id: 08002008D0FD000A7194
Message-Id: <9104261546.AA00620@imsa.edu>
Date: 	Fri, 26 Apr 1991 08:46:02 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: MOO-Cows.PARC@xerox.com
Subject: Re: Permissions

>> Re: UberMUD:
>> ... being able to read and call a function should be the same thing,

> NO!

> My own prejudice is that everyone should be able to *read* every verb
> (i.e., aside from verbs dealing with the particulars of puzzles and
> adventuring scenarios, which should be unreadable so as not to spoil the fun),
> so that they can find out how it all works, have examples of programming style
> (:-) and all that good stuff.  Suffice it to say that calling permissions
> should be a bit more restricted.

    Now, here we're getting into some rather stickey theoretical and
philosophical stuff.  I suppose I should have elaborated on Uber a bit
more before talking about it.  I think I'll just do that now, in an
attempt to make myself a bit more clear.
    For one thing, in Uber, code that you own does not automatically
run with your permissions.  You have to specifically set a 'setuid'
bit (an idea stolen from UNIX) on the code.  If this bit is set, then
it runs wioth your permissions.  Otherwise, it runs with the
permissions of whoever called it.  (Of course, this opens the whole
can of worms of the distinction between 'real user' and 'effective
user'.)  This makes it much easier to protect yourself from
potentially damaging code.  (If you take this into account, maybe you
can see my point about ability to read implying ability to execute, as
what you are concerned about is whose permissions the verb gets
executed with, not really who gets to execute it.  Of course this also
goes into the whole concept of code as just a special kind of data,
but I don't think that's a debate to be carried out here.)  It's
always sort of bothered me that any verb I ever make in MOO runs with
my permissions, but maybe I just got too used to the security of U in
the short time that I played with it.
    Now, if you think about this 'setuid' bit thing, you may also be
able to see my point about 'self' permissions.  Suppose you made some
object that had some property attached to it that needs to be modified
by a verb attached to the same object.  Suppose also that you are
paranoid and don't want this verb to run with your permissions, but
you still want it to be able to modify that property attached to the
same object.  If you could set the property to be 'self-readable' and
the verb to !'setuid', the problem would be solved.  The verb would
run with the player's permissions, but still be able to modify the
property by virtue of the fact that they are attached to the same
object.

//////////////////////////////////////////////////////////////////////
\ Kenneth C Schalk \\\"Is conciousness just a special form of \\\\\\\\  //-\
//////////////////////  hallucination?"--Frank Herbert        //////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All opinions expressed are those \\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.	   	    \\
//////////////////////////////////////////////////////////////////////

From lamping@parc.xerox.com Fri Apr 26 10:10:59 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA02398; Fri, 26 Apr 91 10:10:58 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16288>; Fri, 26 Apr 1991 10:09:16 PDT
Received: from navarro.parc.xerox.com ([13.2.18.19]) by alpha.xerox.com with SMTP id <16288>; Fri, 26 Apr 1991 10:06:14 PDT
Received: by navarro.parc.xerox.com id <36097>; Fri, 26 Apr 1991 10:07:48 -0700
Fake-Sender: lamping@parc.xerox.com
X-Ns-Transport-Id: 08002008D0FD000A72AF
In-Reply-To: "Kenneth C. Schalk's message of Fri, 26 Apr 1991 08:46:02 PDT <9104261546.AA00620@imsa.edu>"
Message-Id: <91Apr26.100748pdt.36097@navarro.parc.xerox.com>
Date: 	Fri, 26 Apr 1991 10:07:36 PDT
From: John Lamping <lamping@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: Re: Permissions

>     For one thing, in Uber, code that you own does not automatically
> run with your permissions.  You have to specifically set a 'setuid'
> bit (an idea stolen from UNIX) on the code.  If this bit is set, then
> it runs wioth your permissions.  Otherwise, it runs with the
> permissions of whoever called it. 

   I think that this is a bad idea.  The question is whether you protect
the caller or the callee.  The Uber way of doing things makes it possible
to protect the callee by turning off the setuid bit.  The MOO way protects
the caller, because you never give away your permissions when you call
another verb.  The Uber way, any verb that I call might use my permissions
to do something terrible, and there is no way to prevent it, except to
refuse to call verbs that aren't setuid (reverting to the MOO case), or to
read and check the code of every verb before calling it (unpractical).  The
MOO way, the callee might need to check to make sure it is not doing
something it shouldn't, but that isn't so hard to do.  I prefer the
automatic prevention of Trojan Horses that the MOO way gives.

   On the other hand, I seem to recall Ken mentioning in an earlier message
an Uber feature that gave a verb some priviledges based on the object the
verb was found on.  That seems to have some nice possibilities, giving a
finer grain of protection and all, and maybe Ken can elaborate it to
MOO-Cows.

From ken@imsa.edu Mon Apr 29 00:32:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05665; Mon, 29 Apr 91 00:32:39 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Mon, 29 Apr 1991 00:28:21 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <16129>; Mon, 29 Apr 1991 00:24:03 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA01433; Mon, 29 Apr 91 02:22:26 CDT
X-Ns-Transport-Id: 08002008D0FD000A82D0
Message-Id: <9104290722.AA01433@imsa.edu>
Date: 	Mon, 29 Apr 1991 00:22:26 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: MOO-Cows.PARC@xerox.com
Subject: Re: Permissions

>The MOO way, the callee might need to check to make sure it is not
>doing something it shouldn't, but that isn't so hard to do.  I prefer
>the automatic prevention of Trojan Horses that the MOO way gives.

    I do see the point here, although it seems a bit limiting.  It is,
in a way, safer to put the burden of security checking on the
programmer.  However, this also prevents some things from being
possible.  For example, what if you wanted to write some function that
would modify some property attached to a character, for some
legitimate reason?  Although the MOO way protects the unknowing user,
U allows more flexibility.  Perhaps code could be made 'setuid' (to
use my/U's/UNIX's term) by default.  Perhaps one might even have to
ask a Wizard to turn off the setuid when necessary.

>...I seem to recall Ken mentioning in an earlier message
>an Uber feature that gave a verb some priviledges based on the object the
>verb was found on.  That seems to have some nice possibilities, giving a
>finer grain of protection and all, and maybe Ken can elaborate it to
>MOO-Cows.

    Actually, I don't beleive I ever said this.  At least I hope I
didn't, as it is incorrect.  In any case, what I meant to say was that
I had this neat idea put into my head between learning U, MOO, and C++
within a relatively short span of time.  Basically the idea was to
introduce a new set of permissions on data objects (i.e. MOO
properties/verbs), except it would affect the access to such data
based not on whose permissions the requesting code is running with,
but rather whether it is attached to the same object as the data in
question.  This new set of permissions would be 'or'ed with any others
that are applicable.  For example, I might own some object with
property 'x' set for 'self-read-write' but not 'world-read-write' or
even 'owner read-write'.  However, if I had some verb 'y' attached to
the same object, y would be able to read and modify x.  (Of course,
this could do funny things to 'namespaces' as were mentioned earlier,
as depending on the definitions, such 'self-only-read' data items
might pass in and out of the namespace depending on what object the
current verb is attached to.)  While this is a very interesting
subject, I'm afraid that I must postpone further discussion until I am
awake.

//////////////////////////////////////////////////////////////////////
\ Kenneth C Schalk \\\"Is conciousness just a special form of \\\\\\\\  //-\
//////////////////////  hallucination?"--Frank Herbert        //////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All opinions expressed are those \\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.	   	    \\
//////////////////////////////////////////////////////////////////////

From sfwhite@watcgl.waterloo.edu Mon Apr 29 00:54:03 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05686; Mon, 29 Apr 91 00:54:02 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16132>; Mon, 29 Apr 1991 00:51:16 PDT
Received: from watcgl.waterloo.edu ([129.97.128.64]) by alpha.xerox.com with SMTP id <16133>; Mon, 29 Apr 1991 00:46:40 PDT
Received: by watcgl.waterloo.edu
	id <AA06500>; Mon, 29 Apr 91 03:46:24 EDT
X-Ns-Transport-Id: 08002008D0FD000A82E4
Message-Id: <9104290746.AA06500@watcgl.waterloo.edu>
Date: 	Mon, 29 Apr 1991 00:46:24 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: MOO-Cows.PARC@xerox.com, ken@imsa.edu
Subject: Re: Permissions

ken sez:

>> The MOO way, the callee might need to check to make sure it is not
>> doing something it shouldn't, but that isn't so hard to do.  I prefer
>> the automatic prevention of Trojan Horses that the MOO way gives.

> [...] However, this also prevents some things from being
> possible.  For example, what if you wanted to write some function that
> would modify some property attached to a character, for some
> legitimate reason?  Although the MOO way protects the unknowing user,
> U allows more flexibility.  Perhaps code could be made 'setuid' (to
> use my/U's/UNIX's term) by default.  Perhaps one might even have to
> ask a Wizard to turn off the setuid when necessary.

in moo 2.0, there is a setprogrammer() function, wizard only, which
sets the effective user id (the programmer, since moo permissions
are keyed off the programmer) to its argument for the remaineder of
the verb.

this is useful for things like the built-in commands like @show,
etc, where you want it to run with the permissions of the player.

another way to do permissions which i've been thinking about is to
have the object itself be the only thing which can read or write the
properties (which then become like internal static variables) and
use message passing (verb calls) to manipulate the values.

-- stephen/ghond, actually toying with the idea of DistMOO (horrors)

From yduj@lucid.com Mon Apr 29 07:49:20 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA06256; Mon, 29 Apr 91 07:49:19 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16150>; Mon, 29 Apr 1991 07:47:22 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16150>; Mon, 29 Apr 1991 07:44:58 PDT
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA03824g; Mon, 29 Apr 91 07:44:14 PDT
Received: by boston-harbor id AA20676g; Mon, 29 Apr 91 10:47:29 EDT
X-Ns-Transport-Id: 08002008D0FD000A84D4
Message-Id: <9104291447.AA20676@boston-harbor>
Date: 	Mon, 29 Apr 1991 07:47:29 PDT
From: Judy Anderson <yduj@lucid.com>
To: MOO-Cows.PARC@xerox.com
Subject: Prepositions

Could we have "off" added to the list of prepositions?  I ended up
using "from" which wasn't so bad, but "push person off pool toy" seems
more natural to me than "push person from pool toy".

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'

From pavel@parc.xerox.com Mon Apr 29 10:35:19 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA06559; Mon, 29 Apr 91 10:35:19 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16184>; Mon, 29 Apr 1991 10:33:26 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16179>; Mon, 29 Apr 1991 10:27:22 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 29 Apr 1991 10:27:10 -0700
X-Ns-Transport-Id: 08002008D0FD000A86C8
In-Reply-To: <9104290746.AA06500@watcgl.waterloo.edu>
Message-Id: <91Apr29.102710pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 29 Apr 1991 10:26:56 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: sfwhite@watcgl.waterloo.edu
Cc: MOO-Cows.PARC@xerox.com, ken@imsa.edu
Subject: Re: Permissions

Stephen White writes:
> in moo 2.0, there is a setprogrammer() function, wizard only, which
> sets the effective user id (the programmer, since moo permissions
> are keyed off the programmer) to its argument for the remaineder of
> the verb.

The LambdaMOO function with the same effect is called 'set_task_perms()'.

	Pavel/Haakon

From pavel@parc.xerox.com Mon Apr 29 19:39:15 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA08229; Mon, 29 Apr 91 19:39:14 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16232>; Mon, 29 Apr 1991 19:37:06 PDT
Received: from lambda.parc.xerox.com ([13.1.101.87]) by alpha.xerox.com with SMTP id <16232>; Mon, 29 Apr 1991 19:34:25 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 29 Apr 1991 19:33:58 -0700
X-Ns-Transport-Id: 08002008D0FD000A8DFC
Message-Id: <91Apr29.193358pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 29 Apr 1991 19:33:55 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: LambdaMOO changing its network address

Sometime in the afternoon of Wednesday, May 1st, 1991 (LambdaMOO Standard
Time), the machine running the LambdaMOO server (lambda.parc.xerox.com) will be
changing its numeric network address.  After a few hours, most hosts around the
Internet will have flushed their old ideas about its numeric address and gotten
the new information from the various name servers.  For that few hours, though,
it is quite possible that you will have trouble connecting to the server under
the name 'lambda.parc.xerox.com'; instead, you will have to use its new numeric
address: '13.2.116.36'.  If you have trouble connecting after Wednesday
evening, please send mail to me at lambda@xerox.com and I'll try to fix the
problem.

	Pavel/Haakon

From lamping@parc.xerox.com Thu May  2 10:54:22 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14300; Thu, 2 May 91 10:54:21 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16169>; Thu, 2 May 1991 10:51:44 PDT
Received: from navarro.parc.xerox.com ([13.2.18.19]) by alpha.xerox.com with SMTP id <16146>; Thu, 2 May 1991 10:43:15 PDT
Received: by navarro.parc.xerox.com id <36097>; Thu, 2 May 1991 10:46:07 -0700
Fake-Sender: lamping@parc.xerox.com
X-Ns-Transport-Id: 08002008D0FD000AAF32
Message-Id: <91May2.104607pdt.36097@navarro.parc.xerox.com>
Date: 	Thu, 2 May 1991 10:45:55 PDT
From: John Lamping <lamping@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: Re: Permissions

Ken Schalk suggest:

> a new set of permissions on data ... would affect the access to such data
> based not on whose permissions the requesting code is running with, but
> rather whether it is attached to the same object as the data in question.

Thinking about this, I wondered how best to define "attached to the same
object" in the context of inheritance.  Suppose an object, frob, defines a
property, prop, which is marked "verbs on same object can access".  Further
suppose another object, blortz, is a descendant of frob, and thus inherits
the property prop.  The question is what verbs should have access to
blortz.prop?

I propose that any verb defined on blortz should have access, as should any
verb defined on frob, and any verb defined on an object between frob and
blortz in the inheritance hierarchy.  That is, access should be given to
any verb defined between the object that defines the property and the
object that has the particular property instance, inclusive, but access
should not be given to verbs defined ancestors of the object that defined
the property.

This proposal provides both for customizability and protection.

If I start with an object that defines some properties, and then make an
instance of that object, I can specialize the instance by writing verbs on
the instance that can manipulate the properties.  Then I can can make an
instance of that specialized instance, and the inherited verbs will work on
the new instance.

On the other hand, suppose that I want to use one of Frand's generic
objects, but add a few of my own properties.  I can make an instance of
Frand's object, add my properties, and be assured that no verb on Frand's
generic object will get its alien appendages on my precious private
properties.

If I want protection the other way, that is to ensure that only verbs
defined on the object that defines a property will be able to access the
property, even on instances of the object, I just don't turn on the "verbs
on same object can access" bits.

Finally, this idea proposal provides protection both from malevolent
players, and from coding errors in verbs that are defined on inappropriate
objects.  It could be changed to just provide protection from malevolent
players, by saying that access is given to any verb owned by the owner of
an object between the object that defines the property and the object that
has the particular property instance, inclusive.  This provides the same
protection from malevolent players, because under the original proposal, a
malevelont player could always add a verb an object he, she, or it owns.

I don't currently have a strong opinion on which of the two ways is better,
but I suspect that both shouldn't be supported -- too much confusion.

John Lamping (Aladdin on LambdaMOO)

From ken@imsa.edu Thu May  2 20:20:30 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA15434; Thu, 2 May 91 20:20:29 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16243>; Thu, 2 May 1991 20:18:15 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <16203>; Thu, 2 May 1991 20:16:28 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA08323; Thu, 2 May 91 22:14:57 CDT
X-Ns-Transport-Id: 08002008D0FD000AB62E
Message-Id: <9105030314.AA08323@imsa.edu>
Date: 	Thu, 2 May 1991 20:14:57 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: moo-cows@parc.xerox.com
Subject: Re: Permissions

John Lamping writes:

>...That is, access should be given to
>any verb defined between the object that defines the property and the
>object that has the particular property instance, inclusive, but access
>should not be given to verbs defined ancestors of the object that defined
>the property.

    Of course.  I should have said this in the mail that I sent
elaborating on this idea, but at the time it had gotten rather late, I
wasn't thinking entirely clearly, and I had to force myslef to end it
after I fell asleep at the keyboard.  (Modems shall be the death of
me.)

>...It could be changed to just provide protection from malevolent
>players, by saying that access is given to any verb owned by the owner of
>an object between the object that defines the property and the object that
>has the particular property instance, inclusive.  This provides the same
>protection from malevolent players, because under the original proposal, a
>malevelont player could always add a verb an object he, she, or it owns.

    I'm not sure that I like this particular idea for a couple of
reasons.  First of all, it sounds like it could slow the permission-
checking process down quite a bit, as it would have to go back and
find out who the owners of all of the objects are ...(see above)...
which it seems to me could take a considerable chunk of time,
depending on the number of objects in question.  Secondly, it seems to
be getting away of my original intent behind this whole idea, in that
the access perms would be dependent on owners, not location (for lack
of a better term) of the executing verb relative to the property in
question and the definition of said property.

P.S.	Is this thing growing into something that might actually get
implemented, or is it just an odd theoretical exercise?  I'm just
curious, as I was the one who originally came up with the idea...

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/ Kenneth C Schalk, aka ///"Is conciousness just a special form of ///
\ Xorian|Darkman on MUDs \\  hallucination?"--Frank Herbert        \\\  //-\
////////////////////////////////////////////////////////////////////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All opinions expressed are those \\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.	   	    \\
//////////////////////////////////////////////////////////////////////

From pavel@parc.xerox.com Fri May  3 09:35:28 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA16177; Fri, 3 May 91 09:35:27 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16280>; Fri, 3 May 1991 09:32:42 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <16274>; Fri, 3 May 1991 09:29:26 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 3 May 1991 09:29:05 -0700
X-Ns-Transport-Id: 08002008D0FD000ABBC3
In-Reply-To: <9105030314.AA08323@imsa.edu>
Message-Id: <91May3.092905pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 3 May 1991 09:28:55 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: ken@imsa.edu
Cc: moo-cows@parc.xerox.com
Subject: Re: Permissions

Kenneth C. Schalk writes:
> P.S.	Is this thing growing into something that might actually get
> implemented, or is it just an odd theoretical exercise?  I'm just
> curious, as I was the one who originally came up with the idea...

Rest assured that I am watching this discussion closely and that something like
what's being discussed will make it into the server when I do my
property-permissions reformation.

	Pavel

From dxb105@phys.anu.edu.au Sat May  4 00:42:07 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dxb105@phys.anu.edu.au>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB17469; Sat, 4 May 91 00:42:06 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16302>; Sat, 4 May 1991 00:27:03 PDT
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <16526>; Sat, 4 May 1991 00:00:47 PDT
Received: from PHYS.DECnet MAIL11D_V3 by anu.anu.edu.au (5.57/1.0)
	id AA22429; Sat, 4 May 91 11:52:51 EST
Posted-Date: Sat, 4 May 91 11:52:50 EST
X-Ns-Transport-Id: 08002008D0FD000AC289
Message-Id: <9105040152.AA22429@anu.anu.edu.au>
Date: 	Sat, 4 May 1991 09:52:50 PDT
From: dxb105@phys.anu.edu.au (David Bofinger)
To: mc@anu.anu.edu.au
Cc: DXB105@anu.anu.edu.au
Subject: Permissions

lamping@parc.xerox.com "John Lamping"  (Aladdin) writes:
>Ken Schalk suggest:
>> a new set of permissions on data ... would affect the access to such data
>> based not on whose permissions the requesting code is running with, but
>> rather whether it is attached to the same object as the data in question.

I think this idea is flawed, because it tends to make things a nuisance without
making them impossible ("when self-modifying code is outlawed, only the outlaws
will have self-modifying code", as they say in the classics). As it stands, if
I want to do something, either I'm allowed to or not. Under this proposal, you
will gain special abilities if you write the verb you want to do have do
something on a particular object you own. Objects then become, in a sense,
gateways (if abused, trojan horses). Perhaps I can make this clearer by asking,
what is the purpose of preventing a verb foo that I own from doing something
that a verb bar is allowed to do? If I really want to desperately enough, I can
reprogram bar to do it for me, so why make it difficult?

>I propose that any verb defined on blortz should have access, as should any
>verb defined on frob, and any verb defined on an object between frob and
>blortz in the inheritance hierarchy.  That is, access should be given to
>any verb defined between the object that defines the property and the
>object that has the particular property instance, inclusive, but access
>should not be given to verbs defined ancestors of the object that defined
>the property.

This fells like the right way to implement protection in an OO environment,
looking at the ancestor list between you and where the object is defined. My
own version of this, which is much closer to what MOO is today, is that a verb
can manipulate a prop if any of the following are true:
	1. running with the permissions of the owner of frob.prop
	2. running with wizard permissions.
	3. appropriate bit (r or w) set.
	4. c bit set and running with the permissions of the owner of at least
		one of the objects in [blortz..frob].

Note: without the c bit proviso, one cannot, say, define a pennies property on
a player and have it impossible for the player to manipulate that property.

The only problem I see is that Frand, say, would have the ability to modify the
desc and/or name of any player who reparented to Frand's character class. It's
a hassle. That could turn out to be a fatal flaw... 

[>Two good points of Ken & Roger's system deleted, they both apply to the one I
  am describing as well.]
[>A comment implying something like a c bit deleted.]

>Finally, this idea proposal provides protection both from malevolent
>players, and from coding errors in verbs that are defined on inappropriate
>objects.

Wow, this I gotta see. But can it dance? :-)

[>A brief description of something that sounds a bit like the one I describe,
  but is implied to provide less protection against coding errors than does
  the Schalk-Lamping method. I don't believe I see why. Take a look at
  LambdaRPG sometime to see how objects like #46, #74, #258, #259 commit
  atrocities upon each other's properties. Sure, it could be done with verb
  calls ("messages?") but it would be a lot more work.]

>I don't currently have a strong opinion on which of the two ways is better,

I do. Objects don't kill players, players kill players. Hold them responsible,
and base permission on _who_ is doing something, not on what they're using to
do it.

>but I suspect that both shouldn't be supported -- too much confusion.

Certainly true.

>>(Modems shall be the death of me.)

A slow and lingering one, I presume, one byte at a time. :-)

>>    I'm not sure that I like [A player not object based permissions system,
>> roughly] [because] it sounds like it could slow the permission-
>> checking process down quite a bit.

Perhaps, but at least it's being done in server. Better ten lines in the server
than one in the db, as far as speed is concerned. (I presume Haakon will
correct me if I'm wrong on that.) Bear in mind the deepest parenting chain on
LambdaMOO is only (last I looked) about nine elements long.

>> Secondly, it seems to be getting away [the idea that] the access perms
>> would be dependent on owners, not location (for lack of a better term) of
>> the executing verb relative to the property in question and the definition
>> of said property.

I agree entirely.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
		MOO:	Gary_Severn et al
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"When a scientific genius becomes involved in the mystical mumbo-jumbo, the
    result is likely to be a lunatic whose quest for eternal life massacres
    everything in sight, but such poor souls wouldn't willingly harm a fly"
					-- Barry Hughart, `Bridge of Birds'

From ken@imsa.edu Mon May  6 17:40:17 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA20332; Mon, 6 May 91 17:40:16 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16324>; Mon, 6 May 1991 17:34:04 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <16716>; Mon, 6 May 1991 10:57:06 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA15037; Sat, 4 May 91 16:28:43 CDT
X-Ns-Transport-Id: 08002008D0FD000AC536
Message-Id: <9105042128.AA15037@imsa.edu>
Date: 	Sat, 4 May 1991 14:28:43 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: moo-cows@parc.xerox.com
Subject: More on Permissions

David Bofinger <dxb105@phys.anu.edu.au> writes:

>I think this idea is flawed, because it tends to make things a
>nuisance without making them impossible ("when self-modifying code is
>outlawed, only the outlaws will have self-modifying code", as they say
>in the classics)

    First, I don't see how this idea makes anythign a nuisance.
Second, self-modifying code is fun :-)

>Perhaps I can make this clearer by asking, what is the purpose of
>preventing a verb foo that I own from doing something that a verb bar
>is allowed to do? If I really want to desperately enough, I can
>reprogram bar to do it for me, so why make it difficult?

    The point of this whole thing is not to prevent programmers from
doing something which they otherwise would not be able to do.  The
point *is* to *allow* them to do things which they otherwise *wouldn't
be able to do*.  (Maybe this is just a difference in viewpoint, but I
tend to think mine is a bit more positive.)  What you're saying here
to me seems to be analogous to saying that because your favorite TV
show isn't shown 24 hours a day on every channel, that it is a
nuisance for you to see it, without it being impossible.  After all,
you could just tape it, so why shouldn't they just show it all the
time?  (No major flames intended here, just a little perspective.)

>Objects then become, in a sense, gateways (if abused, trojan horses).

>The only problem I see is that Frand, say, would have the ability to
>modify the desc and/or name of any player who reparented to Frand's
>character class. It's a hassle. That could turn out to be a fatal
>flaw...

    Of course, this can be abused/misused.  However, it sure would
seem silly to set the name and desc to 'self-writeable'.

>I do [have a strong opinion on which of the two ways is better].
>Objects don't kill players, players kill players. Hold them
>responsible, and base permission on _who_ is doing something, not on
>what they're using to do it.

    Of course, players should always be able to be held responsible
for their actions. I never said that they shouldn't The idea behind
this is not to allow players to gain anonymity through the use of
certain objects.  The point is to allow certain verbs to read/modify
certain things on the object to which they are attached, even if the
owner of the verb might not ordinarily be able to do so.

>>>    I'm not sure that I like [A player not object based permissions system,
>>> roughly] [because] it sounds like it could slow the permission-
>>> checking process down quite a bit.

    I feel that I'm being rather misquoted here.  I never said that I
didn't like player based permission systems.  They work very nicely
for *most* situations.  However what I have been trying to help hammer
out here is a non-player based set of permissions.  What I was saying
that I didn't like in the bit above was the idea of making this set of
permission, but then backtracking and just making it a way to say that
'anyone who owns a verb on an object defined between this object and
the one on which property X is defined can read and/or write property
X'.  This seems to me:

    1) to be getting away from the spirit of the idea, in that it just
    goes back to player-based when the whole point (as far as I
    intended) was for an object(hierarchy)-based system and

    2) like it might take considerable time to back-track along the
    chain of parents and check the owners of every verb to see if any
    of them are the player with whose permissions the read/write
    request was made.

>>> Secondly, it seems to be getting away [the idea that] the access perms
>>> would be dependent on owners, not location (for lack of a better term) of
>>> the executing verb relative to the property in question and the definition
>>> of said property.

>I agree entirely.

    Again, I feel misquoted.  I'm afraid my phrasing may not have been
perfectly clear the first time, so let me say again, what I said a few
lines back: My intent was to make a set of permissions that would be
based on the location of a verb's definition within the hierarchy of
classes relative to the definition of a given property, rather than
based on whose permissions the given verb was running with.  To use
John's suggested method of back-tracking along the class hierarchy,
finding all of the owners of any verbs between the property in
question and its definition, and thereby compiling a list of players
who have permission to read and/or write a specific property seems to
go against the (my) original intent in proposing this sort of a
system.

>>>(Modems shall be the death of me.)

>A slow and lingering one, I presume, one byte at a time. :-)

    Actually, its rather speedy, being 2400bps with v.42 BIS.  What I
meant is that it allows me to stay up writing email until I fall
asleep typing.

P.S.	Please excuse all of the long, verbose, run-on-ish sentances,
but this is a difficult thing to explain in small pieces.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/ Kenneth C Schalk, aka ///"Is conciousness just a special form of ///
\ Xorian|Darkman on MUDs \\  hallucination?"--Frank Herbert        \\\  //-\
////////////////////////////////////////////////////////////////////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All opinions expressed are those \\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.                   \\
//////////////////////////////////////////////////////////////////////


From dxb105@phys.anu.edu.au Mon May  6 20:56:37 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dxb105@phys.anu.edu.au>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB21103; Mon, 6 May 91 20:56:36 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16131>; Mon, 6 May 1991 20:53:51 PDT
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <16536>; Mon, 6 May 1991 19:30:14 PDT
Received: from PHYS.DECnet MAIL11D_V3 by anu.anu.edu.au (5.57/1.0)
	id AA06101; Tue, 7 May 91 10:47:09 EST
Posted-Date: Tue, 7 May 91 10:47:08 EST
X-Ns-Transport-Id: 08002008D0FD000AD3F1
Message-Id: <9105070047.AA06101@anu.anu.edu.au>
Date: 	Tue, 7 May 1991 08:47:08 PDT
From: dxb105@phys.anu.edu.au (David Bofinger)
To: mc@anu.anu.edu.au
Cc: DXB105@anu.anu.edu.au
Subject: Permissions

Ken Schalk quotes:
>David Bofinger <dxb105@phys.anu.edu.au> writes: 
>>I think this idea is flawed, because it tends to make things a
>>nuisance without making them impossible

What I'm trying to say is, from a security point of view either a player is
allowed to do something or %s is not. If I own a verb which is permitted to do
something, then _any_ verb I own is effectively capable of doing the same
thing, if necessary by reprogramming the privileged verb. I therefore believe
that every verb owned by (more strictly, running with the permissions of) any
given player should have the same privileges as any other such verb.

> What you're saying here
>to me seems to be analogous to saying that because your favorite TV
>show isn't shown 24 hours a day on every channel, that it is a
>nuisance for you to see it, without it being impossible.

Yes. The analogy continues that if the program has been banned because it
contains defense secrets you don't want foreign governments to know, then there
is little point to putting it on a 3AM, since then it's a nuisance for honest
people to watch, but the spies can be relied on to stay up. Didn't stop the
British government banning Spycatcher, of course...

>    Of course, [the Frand changes everyone's desc problem] can be
> abused/misused.  However, it sure would seem silly to set the name and desc
> to 'self-writeable'.

That's a bit upsetting. It's just what I was going to suggest...

>    Again, I feel misquoted.

Looks like I misunderstood you pretty badly. My attitude is that permission to
do something and responsibility for doing something should both be based on the
same thing. responsibility is clearly a player concept, not an object concept.
So permissions should be the same. I realise that is entirely inconsistent with
Ken's philosophy, but I don't think I understand what his motivation is for
such a formalism.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
		MOO:	7G and reflections
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"Through the night of doubt and sorrow 
 Onward goes the pilgrim band.
 Counting photons very slowly
 On the fingers of one hand."		-- The Lay of the Gamma-Ray Astronomer

From latour!mcr Mon May  6 21:36:13 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21190; Mon, 6 May 91 21:36:12 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16134>; Mon, 6 May 1991 21:34:15 PDT
Received: from alfred.ccs.carleton.ca ([134.117.1.1]) by alpha.xerox.com with SMTP id <16132>; Mon, 6 May 1991 21:24:04 PDT
Received: from latour.UUCP by alfred.ccs.carleton.ca (4.1/SMI-4.0)
	id AA09438; Tue, 7 May 91 00:23:16 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA27236; Mon, 6 May 91 22:37:25 EDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD000AD64B
In-Reply-To: "ken@imsa.edu (Kenneth C. Schalk)
       \"More on Permissions\" (May  4,  2:28pm)"
Message-Id: <9105070237.AA27236@Sandelman.OCUnix.On.Ca>
Date: 	Mon, 6 May 1991 19:37:24 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: ken@imsa.edu (Kenneth C. Schalk), moo-cows@parc.xerox.com
Subject: Re: More on Permissions

On May 4,  2:28pm, Kenneth C. Schalk wrote:
}     I feel that I'm being rather misquoted here.  I never said that I
} didn't like player based permission systems.  They work very nicely
} for *most* situations.  However what I have been trying to help hammer
} out here is a non-player based set of permissions.  What I was

  This I like. Players are, in the end, just objects that can produce
commands :-) (Maybe preparsed command trees too. Make the clients that
can do some work, do it.) 
  Meta-MOO would be very nice...

} that I didn't like in the bit above was the idea of making this set
} permission, but then backtracking and just making it a way to say

  Are you just worried about the time complexity of doing this? [Not to
mention the potential for VM trashing --- but the appropriate
hierarchy would just have to become part of the working set]

}     2) like it might take considerable time to back-track along the
}     chain of parents and check the owners of every verb to see if any
}     of them are the player with whose permissions the read/write
}     request was made.

  But the verb has to found anyway right?  I may have missed something
along the way. The proposal was to allow a verb, defined on an object
to modify another prop that was on the same object right? As far as I
can tell, if A.foo is defined, and B's parent is A, B can not also
define B.foo, so there is at most one .foo in the chain of parents.
  
  I'm going to have review my archive...


-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!



From ken@imsa.edu Tue May  7 00:28:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21363; Tue, 7 May 91 00:28:28 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Tue, 7 May 1991 00:26:22 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <16139>; Tue, 7 May 1991 00:22:30 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA29689; Tue, 7 May 91 02:20:59 CDT
X-Ns-Transport-Id: 08002008D0FD000AD7AF
Message-Id: <9105070720.AA29689@imsa.edu>
Date: 	Tue, 7 May 1991 00:20:59 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: moo-cows@parc.xerox.com
Subject: Permissions (yes, more permissions)

David Bofinger <dxb105@phys.anu.edu.au> writes:

>[...] I don't think I understand what [Ken's] motivation is for such a
>formalism.

    OK.  I must apologize for all this confusion I have caused.  I
will now attempt to explain how and why this discussion got started,
and what motivated me into it.  I am a professional.  Do not try this
at home.
    Basically, this whole idea began as a mental exercise as a result
of several things that I have been learning and experimenting with in
the recent past.  Most important of these to this discussion are:
UberMUD, C++, and MOO.  Anyway, I had this idea, and, not knowing what
to do with it, mentioned it in passing in moo-cows, thinking that
someone might catch it and be interested enough to attempt a
discussion of it.  Unfortunately, I wan't specifically thinking in
terms of MOO when I cam up with this idea, and I'm no longer sure how,
if at all, this fits into the MOO model.  (OK, I admit it; I still
think in UberMUD terms sometimes.)  Let me elaborate with an example.

    (I'm going to attempt to do this in non-MUD-type-specific terms,
so please bear with me.)  Let's say that I own some object with a
property attached that normally I only want me to be able to modify or
read.  Let's say that this object also has some well-behaved piece of
code attached to it that I want to be able to read and/or write this
normally private property.  However, by the grace of some Wizard, this
piece of code runs with the permissions of whatever player invokes it.
(Yes, I realize that in MOO this is a practically non-existent
situation.)  Now if I could set this property's permissions so that it
could be read and/or written by code attached to the same object (or
any of its ancestors), the problem would be solved.  The code would
not run with my permissions, yet it would be able to access that
specific piece of data.

    This is the basic example that I had in my head when I came up
with this idea.  This theoretical set of permissions qould only be for
use when you want a well-behaved piece of code to run with someone
else's permissions but still be able to access very specific pieces of
data which it otherwise would be unable to.  I guess the crux of this
whole thing is that the code (verb) in question needs to be
well-behaved.  (Of course, you can say 'But if the code is
well-behaved, why not just let it run with your permissions?'
However, there are times when you would want it to run with someone
else's permissions.  Please, don't ask me for examples right now, it's
too early in the morning.)
    Yes, if someone else has total control over the code and can run
around doing whatever they want with it, then this could be a
potential security leak.  Yes, permission and responsibility should be
very closely related, but at certain times, you may want to allow
someone else to read/write something, as long as it is in a very
specific well-defined way.  As I said before, the point of all this is
not to prevent you from doing something *except* in a very *difficult*
way, it is to allow you to do something *only* in a very *specific*
way.

    I sincerely apologiza to everyone reading for not havign tried to
spell this out as clearly as I hope I now have.  I guess that I
thought it was more obvious than it actually is.

Michael Richardson <mcr@sandelman.ocunix.on.ca> writes:

>} that I didn't like in the bit above was the idea of making this set
>} permission, but then backtracking and just making it a way to say
>
>  Are you just worried about the time complexity of doing this?

    No.  It bothers me to do it this way, because it seems to go
against my original intent with this idea.  (Is it just me, or have I
said this several times?)  I was suggesting a set of permissions be
introduced that was *not* based on which player's permissions the
current verb was executing with.  To me it seems like a terribly silly
thing to introduce something that would have the same effect as this,
but sidesteps the idea of a set of non-player-based permissions (and,
in my opinion, in a rather kludgey way), turning it back into just
another set of permissions for a different set of players, while in
the process chewing up lots of CPU cycles.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/ Kenneth C Schalk, aka ///"Is conciousness just a special form of ///
\ Xorian|Darkman on MUDs \\  hallucination?"--Frank Herbert        \\\  //-\
////////////////////////////////////////////////////////////////////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All opinions expressed are those \\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.                   \\
//////////////////////////////////////////////////////////////////////

From dxb105@phys.anu.edu.au Tue May  7 01:40:30 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dxb105@phys.anu.edu.au>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21591; Tue, 7 May 91 01:40:29 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16139>; Tue, 7 May 1991 01:38:40 PDT
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <16139>; Tue, 7 May 1991 01:10:17 PDT
Received: from PHYS.DECnet MAIL11D_V3 by anu.anu.edu.au (5.57/1.0)
	id AA08233; Tue, 7 May 91 17:30:11 EST
Posted-Date: Tue, 7 May 91 17:30:10 EST
X-Ns-Transport-Id: 08002008D0FD000AD81E
Message-Id: <9105070730.AA08233@anu.anu.edu.au>
Date: 	Tue, 7 May 1991 15:30:10 PDT
From: dxb105@phys.anu.edu.au (David Bofinger)
To: mc@anu.anu.edu.au
Cc: DXB105@anu.anu.edu.au
Subject: Permissions again, but I'll keep it short, right?

Actually, I'm only using this post to ask if there's any interest and/or
possibility in the idea of having perms that are regular expressions of some
sort (the verb owner's permissions get &&ed on the front of everything). But
I'll answer Ken so I have some excuse.

Ken Schalk writes:
> [First half of example deleted] However, by the grace of some Wizard, this
>piece of code runs with the permissions of whatever player invokes it.
>(Yes, I realize that in MOO this is a practically non-existent situation.)

Actually no, that situation is quite common. The point is that if a wizard is
involved all your permissions problems become, if not trivial, at least
soluble. My visualisation of permissions is that they are mostly for the
benefit of ordinary people.

>As I said before, the point of all this is not to prevent you from doing
>something *except* in a very *difficult* way, it is to allow you to do
>something *only* in a very *specific* way.

I don't see the point of either. If you're going to let someone do something,
why not let them use whatever method they choose? (In this case method==verb,
although method is not being used in the sense in which it usually is when it
means verb... *sigh*). My idea of permissions is they only let you do things
under certain circumstances, not in certain ways.

>(Is it just me, or have I said this several times?)

I think you've told us three times. I understood the second time, but of course
I had to hear it a third time so the different interpretations could vote on
which was faulty. :-) When I asked your motivation I was aiming at something
one level deeper than the answer I got. _My_ motivation is, I guess, to have a
permissions system that will solve the classic "radio" (solvable in current
LambdaMOO) "generic sittable object" (needs a verb :set_sitting, ugly) and
"CyberFile" (child megacorps cannot directly access the properties on CyberMOO
CyberFiles, because they belong to 7G) problems. Without creating anything like
a "Frand desc" problem. I think we're going to need an extra bit, myself, much
as I hate the idea.

>I was suggesting a set of permissions be introduced that was *not* based on
>which player's permissions the current verb was executing with.

This strikes me as unsound. Which probably means, Ken, that we have no room for
negotiation whatsoever. As I see it, you either trust a player to manipulate
some instantiation of a property or you don't. _How_ %s does it is %p business.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
		MOO:	Black_Norway, and her fronts
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"It could be worse"
"Yeah. It could be raining." - `Promised Land', Brian Stableford

From pavel@parc.xerox.com Fri May 10 11:27:56 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA07512; Fri, 10 May 91 11:27:55 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <17078>; Fri, 10 May 1991 11:25:24 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <17077>; Fri, 10 May 1991 11:16:28 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 10 May 1991 11:16:04 -0700
X-Ns-Transport-Id: 08002008D0FD000B0AE3
Message-Id: <91May10.111604pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 10 May 1991 11:15:55 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: Upcoming server changes

Michael Richardson asks, in private mail:
> Any word on when there will be the ability to get input from the player??

I am currently nearing completion of version 1.3 of the server, which includes
an overhaul of the network, main-loop, and task-scheduler portions of the
server.  As a result of these changes, `clocks' have been removed, there is a
per-player task queue, and forked tasks get a full supply of ticks when they
start.  Thus, long-running iterative tasks can be implemented by simply forking
(with a delay of 0) whenever seconds or ticks are running low.  In addition,
the processing of commands for un-logged-in players has been moved into the
database, along with the implementations of the QUIT, PREFIX, SUFFIX,
.shutdown, and .dump commands.  The *only* built-in command left is .program.

This set of changes was made in preparation for the set going into version 1.4,
which are centered around changing the MOO program representation from
parse-trees to vectors of opcodes.  With this change, arbitrary task suspension
will become possible and, therefore, the read() primitive will be introduced
at that time.  The .program command will then be rewritten in MOO as a task
that repeatedly uses read().  [Oh, for those who've asked: support for
statements like C's `break' and `continue' (but probably named `exit' and
`loop' instead) will also be included in 1.4, perhaps along with left-hand-side
indexing.]  [[Also, I am very seriously considering changes that would bring
all command parsing into MOO code.  This would *not*, however, significantly
increase the expressive power of verb syntax; we would still be using the
dobj/prep/iobj structure we have now.  See below, though...]]

I expect to release 1.3 next week sometime and then begin work on 1.4 somewhat
later.   The changes for 1.4 are quite sweeping, though, so I'm not sure how
long it will take to complete them and then to sufficiently debug the new
server for release.  Of course, LambdaMOO players will get to try out all of
these changes well before release... :-)

I am proposing to our crop of summer interns here at PARC that one of them work
on changes to the MOO server, and I think I might get someone to take me up on
it.  The following changes are in the pipeline and some significant fraction of
them is likely to be completed by the intern:

   -- Multiple inheritance (already designed by Aladdin and I)
   -- Changing server memory allocation to do reference-counting
      (This brings a significant speed and space savings)
   -- Overhaul of the current property and verb permissions systems
   -- A new, much more expressive system for parsing commands, partially
      designed already by Aladdin and I.

Comments on any of the activities I've mentioned in this message are, of
course, welcome.  At some point later I will be posting for comment detailed
descriptions of some of the changes coming up, especially multiple inheritance,
the new parser, and the changes to the permissions systems.

	Pavel/Haakon/Lambda

From joe@unipress.unipress.com Mon May 13 16:57:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <joe@unipress.unipress.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13189; Mon, 13 May 91 16:57:28 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16219>; Mon, 13 May 1991 16:54:47 PDT
Received: from rutgers.edu ([128.6.4.7]) by alpha.xerox.com with SMTP id <16223>; Mon, 13 May 1991 16:50:19 PDT
Received: from unipress.unipress.com by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with UUCP 
	id AA25094; Mon, 13 May 91 19:26:25 EDT
Received: from dot.unipress.com.unipress by unipress.com (3.2/SMI-3.0DEV3)
	id AA02976; Mon, 13 May 91 18:44:41 EDT
X-Ns-Transport-Id: 08002008D0FD000B282A
Message-Id: <9105132244.AA02976@unipress.com>
Date: 	Mon, 13 May 1991 15:44:41 PDT
From: joe@unipress.unipress.com (Joe Miklojcik)
To: MOO-Cows.PARC@xerox.com

WARNING

These are just ideas I want to share (some might be out of ignorance).
Please don't think I'm trying to be pushy.

SPECIAL CHARACTERS 

I think that special leading character shorthands on the command line
should not be hard wired into expansions.  In fact, I think that the
whole command interpreter should be written in MOO.

This will become more of an issue (more possible) when a read()
primitive is available.  Verbs which must have a dobj and an iobj will
want to prompt for the iobj if it's missing on the initial command
line, for example.

kiw da wabbit
How do you intend to kiw da wabbit?
wif my speaw and magic hewmet

Furthermore, special purpose command readers could be used for things
like editors and mail readers, so that our location doesn't have to
change to do these things.

The implementation of such command interpreters is hindered by the
hard wiring of special leading character shorthands in obvious ways.

The fact that most of the commands issued on tiny flavored muds start
with '"' or ':' concerned some MOOers with the efficiency of command
parsing.  The '"' ::= "say " expansion (et.  al.) not happening in the
MOO kernel would be inefficient.  However, A primitive for performing
the standard interpretation of a command line could be implemented
which would solve this.

THIS NONE THIS

I was surprised to read in the LambdaMOO Programmer's Manual that the
'x' permission on verbs worked the way it did.  I would have guessed
that it controlled whether or not a verb was callable from the command
line, rather than from a program.  Later I found that the way to make
an "unobvious" verb was to make the verb's dobj, prep, and iobj
specifiers this none and this respectively.  I also now understand the
importance of the 'x' bit's effect.

But the use of the argument specifiers to do this still disturbs me.
First of all, I think that this none this could be useful in a verb on
an object with many aliases.  The iobj and dobj could both be
referring to the same object, but by different names.  Secondly, the
use of argument specifiers to prohibit a verb from being a command is
unintuitive -- especially with 'this none this'.

I propose that a new bit, or a new state for the execute permission of
a verb be introduced.  A verb's execute permission could be ' ' for
anything can execute me, 'x' for command only, and 'p' for program
only.  Not really bit-like, I know, but more easy to remember and
understand.

Failing that, perhaps a special command line argument specifier, say
"never" that will prohibit the verb from being a command.

THANK YOU

--Khalarghast (AKA: Joe) joe@dot.unipress.com


From dxb105@phys.anu.edu.au Mon May 13 19:11:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dxb105@phys.anu.edu.au>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13569; Mon, 13 May 91 19:11:44 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16235>; Mon, 13 May 1991 19:07:51 PDT
Received: from anu.anu.edu.au ([130.56.4.1]) by alpha.xerox.com with SMTP id <16233>; Mon, 13 May 1991 19:03:20 PDT
Received: from PHYS.DECnet MAIL11D_V3 by anu.anu.edu.au (5.57/1.0)
	id AA19643; Tue, 14 May 91 11:03:11 EST
Posted-Date: Tue, 14 May 91 11:03:10 EST
X-Ns-Transport-Id: 08002008D0FD000B294A
Message-Id: <9105140103.AA19643@anu.anu.edu.au>
Date: 	Tue, 14 May 1991 09:03:10 PDT
From: dxb105@phys.anu.edu.au (David Bofinger)
To: mc@anu.anu.edu.au
Cc: DXB105@anu.anu.edu.au
Subject: Parsing, etc.

>[joe@unipress.unipress.com (Joe Miklojcik)] was surprised to read in the
>LambdaMOO Programmer's Manual that the 'x' permission on verbs worked the way
>it did.

A conspiracy exists to make !x verbs callable from verbs with the same owner.

>I think that this none this could be useful in a verb on
>an object with many aliases.

No, it is honest-to-goodness useless. The present MOO parser searches for a
preposition and calls everything between the verb and the preposition the dobj
and everything after the preposition the iobj. If it's told not to look for a
prep, It assumes the args are all dobj, so it can never get a this in both dobj
and iobj without a prep to separate them. So this none this just doesn't match
anything, and hence can never be called from the command line. It's not written
into the server explicitly.

A message for those keen on having the matcher in db: why not try an experiment
now? Take an expendable character :-), and put a verb * any any any on them,
that does the matching. You may have some trouble with !x verbs, though.

(I deleted Joe's comments on making the punctuation substitutions a primitive,
I don't feel as strongly as he does, but it seems at worst harmless.)
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
		MOO:	7G and reflection
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------
"We use the classical theory on Mondays, Wednesdays and Fridays, and the
quantum theory on Tuesdays, Thursdays and Saturdays." -- Sir William Bragg

From vision@elof.iit.edu Thu May 16 13:01:33 1991
X-VM-Attributes: [nil nil nil nil t]
Status: RO
Return-Path: <vision@elof.iit.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21358; Thu, 16 May 91 13:01:32 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16230>; Thu, 16 May 1991 12:58:42 PDT
Received: from iitmax.iit.edu ([192.41.245.10]) by alpha.xerox.com with SMTP id <16220>; Thu, 16 May 1991 12:51:05 PDT
Received: from elof.iit.edu by iitmax.iit.edu with SMTP id AA00753
  (5.64+/IDA/NIU-1.3.1 for Moo-Cows@xerox.com); Thu, 16 May 91 14:51:09 -0600
Received: by  elof.iit.edu.iit.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA27203; Thu, 16 May 91 14:51:05 GMT-0300
X-Ns-Transport-Id: 08002008D0FD000B4C13
Message-Id: <9105161751.AA27203@elof.iit.edu.iit.edu>
Date: 	Thu, 16 May 1991 10:51:05 PDT
From: vision@elof.iit.edu (vision)
To: MOO-Cows.PARC@xerox.com
Subject: Programmer's Docs

In the Lambda database core, it says that plain-text docs can be found
at belch.berkeley.edu; I found .tex .ps, and .info docs, but no normal
set of them. Could someone put them on belch, or let me know where I
should go to find them? (I'm playing around with a test-moo and don't
really know what I'm doing yet).
   -Desmodus

P.S. Greetings, everyone :)

From pavel@parc.xerox.com Thu May 16 15:30:28 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21799; Thu, 16 May 91 15:30:27 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16600>; Thu, 16 May 1991 15:27:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <16603>; Thu, 16 May 1991 15:15:57 PDT
Received: by lambda.parc.xerox.com id <58369>; Thu, 16 May 1991 15:15:38 -0700
X-Ns-Transport-Id: 08002008D0FD000B4E2F
In-Reply-To: <9105161751.AA27203@elof.iit.edu.iit.edu>
Message-Id: <91May16.151538pdt.58369@lambda.parc.xerox.com>
Date: 	Thu, 16 May 1991 15:15:27 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: vision@elof.iit.edu
Cc: MOO-Cows.PARC@xerox.com
Subject: Re: Programmer's Docs

> In the Lambda database core, it says that plain-text docs can be found
> at belch.berkeley.edu; I found .tex .ps, and .info docs, but no normal
> set of them.

The .texinfo version of the documentation is quite human-readable and is, for
the moment, the best we've got.  I am given to understand that the fellow
responsible for fixing bugs in the texinfo-to-plaintext program has my bug list
as number three on his queue, so who knows how much longer we'll have to wait.

	Pavel

From vision@elof.iit.edu Thu May 16 17:21:34 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <vision@elof.iit.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA22082; Thu, 16 May 91 17:21:33 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16641>; Thu, 16 May 1991 17:19:05 PDT
Received: from iitmax.iit.edu ([192.41.245.10]) by alpha.xerox.com with SMTP id <16630>; Thu, 16 May 1991 16:33:10 PDT
Received: from elof.iit.edu by iitmax.iit.edu with SMTP id AA02825
  (5.64+/IDA/NIU-1.3.1 for Moo-Cows@xerox.com); Thu, 16 May 91 18:33:19 -0600
Received: by  elof.iit.edu.iit.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA05446; Thu, 16 May 91 18:33:14 GMT-0300
X-Ns-Transport-Id: 08002008D0FD000B4F60
Message-Id: <9105162133.AA05446@elof.iit.edu.iit.edu>
Date: 	Thu, 16 May 1991 14:33:14 PDT
From: vision@elof.iit.edu (vision)
To: MOO-Cows.PARC@xerox.com
Subject: Docs

I made a trip (4 blocks?) to campus and printed out the docs, so I'm set..
{Is anyone else having the problem that *.xerox.com is unreachable, thru
telnet? I'd like to check out LambdaMOO but I haven't been able to connect 
for the past couple days.  Mail (obviously) is working fine, so there
must be an open route somewhere.
   -Desmo

From pavel@parc.xerox.com Thu May 16 09:41:52 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA20860; Thu, 16 May 91 09:41:51 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16173>; Thu, 16 May 1991 09:38:21 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <16182>; Thu, 16 May 1991 09:31:45 PDT
Received: by lambda.parc.xerox.com id <58369>; Thu, 16 May 1991 09:31:29 -0700
X-Ns-Transport-Id: 08002008D0FD000B4944
Message-Id: <91May16.093129pdt.58369@lambda.parc.xerox.com>
Date: 	Thu, 16 May 1991 09:31:22 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: Mailing list test message #1

I am in the process of changing the way in which I administer the MOO-Cows
mailing list.  You should receive another message with subject line `Mailing
list test message #2' within a short time of receiving this one.  This one was
sent using the old mailing list and message #2 is sent using the new list.
Please let me know if you receive one and not the other.

	Pavel

From pavel@arisia.Xerox.COM Thu May 16 09:45:17 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA20877; Thu, 16 May 91 09:45:16 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA21152; Thu, 16 May 91 09:32:14 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <16165>; Thu, 16 May 1991 09:32:09 PDT
Received: by lambda.parc.xerox.com id <58369>; Thu, 16 May 1991 09:32:01 -0700
Message-Id: <91May16.093201pdt.58369@lambda.parc.xerox.com>
Date: 	Thu, 16 May 1991 09:32:00 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@arisia.Xerox.COM
Subject: Mailing list test message #2

I am in the process of changing the way in which I administer the MOO-Cows
mailing list.  You should receive another message with subject line `Mailing
list test message #1' within a short time of receiving this one.  This one was
sent using the newmailing list and message #1 is sent using the old list.
Please let me know if you receive one and not the other.

	Pavel

From pavel@arisia.Xerox.COM Mon May 20 13:45:56 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA01340; Mon, 20 May 91 13:45:55 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01039; Mon, 20 May 91 13:36:02 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <16196>; Mon, 20 May 1991 13:35:53 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 20 May 1991 13:35:44 -0700
Message-Id: <91May20.133544pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 20 May 1991 13:35:36 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: New mailing list implementation

OK, folks, we're now using the new method of running this mailing list.  Please
let me know if you have any problems using it at all.  In particular, I believe
that only I should receive any bounced-mail notifications now.

	Pavel

From crew@neon.stanford.edu Fri Jun  7 11:41:43 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA04123; Fri, 7 Jun 91 11:41:42 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA06381; Fri, 7 Jun 91 11:36:06 -0700
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11580>; Fri, 7 Jun 1991 11:35:59 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA09678; Fri, 7 Jun 91 11:35:52 -0700
Message-Id: <9106071835.AA09678@Neon.Stanford.EDU>
Date: 	Fri, 7 Jun 1991 11:35:50 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@arisia.Xerox.COM
Subject: ticks and associativity

It seems strange that 

    cond ? thenclause | elseclause 

    return a && b;

each cost one tick while the corresponding conditional statements

    if(cond) 
      thenclause; 
    else 
      elseclause; 
    endif

    if(a) 
      return a; 
    else 
      return b; 
    endif 

cost nothing.  While one could go through and try to decide which
sorts of expressions should be charged and which shouldn't, I would
say that the easiest way to restore equity would be to have
if(...) statements be charged 1 tick.  Seeing as you're already doing
this with for/while loops, this shouldn't be too radical a proposal.  

Then, I noticed that 0&&0&&0&&0&&0 costs 4 ticks, yet the server
shouldn't have to do any real work beyond evaluating the first 0.  
The real problem here is that left associativity causes this to parse as 
(0&&0&&0&&0)&&0.  Given their short-circuiting behavior, && and || 
should really be right-associative (i.e., parse as 0&&(0&&0&&0&&0)).

For that matter, as long as we're messing with associativity, 
?| should also be right-associative since a natural thing to want to do is

   cond1 ? then1 | cond2 ? then2 | cond3 ? then3 | otherwise

Contrast this with the left associative

   cond1 ? bool1t | bool1f ? bool2t | bool2f ? thenclause | elseclause

which isn't even readable without the parentheses.


Just out of curiosity, how much effort is involved in dumping a fully
parenthesized db (i.e., as a prelude to making a parser change)?

--
Roger Crew                                        ``I kill Optimax...''
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MUD:       Rog

From pavel@arisia.Xerox.COM Fri Jun  7 17:00:04 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05092; Fri, 7 Jun 91 17:00:02 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA12399; Fri, 7 Jun 91 16:53:44 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11593>; Fri, 7 Jun 1991 16:53:39 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 7 Jun 1991 16:53:24 -0700
Message-Id: <91Jun7.165324pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 7 Jun 1991 16:53:19 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: LambdaMOO Server Version 1.3.0 Released

I have stored out on
	[belch.berkeley.edu]pub/moo/LambdaMOO/LambdaMOO-1.3.0.tar.Z
release 1.3.0 of the LambdaMOO server code.  The change log for this release in
included at the end of this message.

This is a major release of LambdaMOO; many important, central features have
changed.  All sites running version 1.2.0 or earlier are *strongly* advised to
upgrade to this one.  *PLEASE NOTE* that you *must* make at least one change to
your running database *before* starting to use the new server: you must add a
definition for #0:do_login_command().  Failure to do so will make it impossible
to log into your MOO.  A sample implementation appears in the change log,
below.

This release of the server includes, for the first time, full documentation on
the contents and use of the `Minimal' database.  It is still recommended,
however, that you start from an up-to-date LambdaCore database instead.

As usual, I am always interested in hearing about your failures and successes
in bringing up a LambdaMOO server.  In particular, since this release includes
a *much* sharper distinction between the network code and the rest of the
server, I would be interested in hearing about (and receiving) alternate
network implementations (at present, as before, only BSD UNIX-style networking
is supported).

Enjoy!

	Pavel/Haakon/Lambda


Changes in version 1.3.0:

-- Removed the now-useless `.help' and `.mem' commands, and all code concerning
   the also-removed CHECKMALLOC option.
-- Fixed allocation bug in inheritance of 'dobjstr' and its ilk, when the
   current value of the variable has the wrong type (e.g., 'dobjstr' is a list
   when another verb-call happens).
-- Fixed the timers implementation not to try to free storage inside an
   interrupt procedure.
-- Changed move() so that :accept is called even if it's a wizard doing the
   moving; of course, the wizards gets to do the move even if :accept returns
   false.
-- Added 'off/off of' as a new preposition.
-- Fixed the built-in parser to return #-1 ($nothing) for the empty string,
   rather than #-2 ($ambiguous_match).
-- Fixed a few bugs in how the allocator keeps track of types.
-- Fixed two memory leaks:
	 1) If you returned or aborted from inside an iteration over a list,
	    the list was never freed.
	 2) If you killed a task, its associated environment was never freed.
-- Added ticks_left() and seconds_left(), for determining how much longer the
   current task will be allowed to run.
-- Reduced the maximum number of seconds for each task from 60 to 15.
-- Removed restriction that the first argument to notify() and boot_player()
   must be a valid player object.
-- Removed the .shutdown and .dump commands.
-- Added shutdown() and dump_database() functions to replace their respective
   built-in commands.  The shutdown() function takes a single string argument
   that is printed to all players as their connections are closed.
-- Added output_delimiters() as a way to discover the current PREFIX and SUFFIX
   strings on a given connection.
-- Completely rewrote and modularized the network interface (now in
   bsd_network.c), the main loop, connection-management, and checkpointing code
   (now in server.c), and the task dispatcher (now in tasks.c).
-- Eliminated the notion of `clocks' associated with tasks.  All tasks,
   including forked tasks, begin execution with a full complement of ticks and
   seconds.  To make this reasonable, the task dispatcher maintains a separate
   queue per player, with command tasks and ready forked tasks intermingled.
   Thus, a malicious player who forks many tasks can only clog his own queue.
-- Eliminated the `command burst' heuristics from the dispatcher; this always
   seemed like just a patch for having a fair dispatcher anyway.
-- Added a timeout for closing idle un-logged-in connections.
-- Removed the QUIT command; the boot_player() function can now be used for
   that purpose.  boot_player() now does a normal disconnect, including running
   the disfuncs.  At the same time, I made it allow players to boot themselves.
-- Because clocks have been eliminated, the lists returned by queued_tasks()
   have changed somewhat, though in a mostly-compatible way.  The clock ID and
   clock ticks fields are both constant now, with the ticks equal to 20,000.
-- ****************** All processing of commands typed by un-logged-in players
   *** VITAL NOTE *** has been moved into the database.  Every un-logged-in
   ****************** connection is assigned a unique negative player number.
   The functions notify() and boot_player() can be used by wizards to send
   text to and to terminate such a connection, respectively, using that player
   number as the connection identifier.  Each line of input on such a
   connection is first parsed into words in the usual way and then these words
   are passed as the arguments to #0:do_login_command().  For example, the line
   	connect Munchkin frebblebit
   would result in the following call being made:
	#0:do_login_command("connect", "Munchkin", "frebblebit")
   If #0:do_login_command returns a valid player object, then the connection is
   considered to have logged into that player.  When the connection is first
   established, the null command is automatically entered, resulting in a call
   to #0:do_login_command with no arguments.  This signal can be used by the
   verb to print out a welcome message, for example; this service is no longer
   provided by the server.
      Because of this change, it will be **NECESSARY** to add an implementation
   of #0:do_login_command to your database *before* beginning to use version
   1.3.0 of the server.  The Minimal.db database and the version of the
   LambdaCore database released concurrently with 1.3.0 already provide such an
   implementation.  The following code can be used as a simple implementation
   that preserves most of the functionality of version 1.2.0:

	if (callers())
	  "This code should only be run as a server task.";
	  return;
	endif
	if (args == {})
	  args = {"help"};
	endif
	command = args[1];
	args = args[2..length(args)];
	nargs = length(args);
	if (command == "connect")
	  if (nargs < 1)
	    notify(player,
	           "Usage:  connect <existing-player-name> <password>");
	  else
	    name = args[1];
	    password = nargs >= 2 ? args[2] | "";
	    for p in (players())
	      if (p.name == name
	          && (typeof(p.password) != STR
		      || (length(p.password) >= 2
			  && crypt(password, p.password[1..2]) == p.password)))
		p.last_connect_time = time();
		return p;
	      endif
	    endfor
	    notify(player, "Unknown player or wrong password.");
	  endif
	elseif (command == "create")
	  if (nargs != 2)
	    notify(player, "Usage:  create <new-player-name> <new-password>");
	  else
	    name = args[1];
	    password = args[2];
	    for p in (players())
	      if (p.name == name)
		notify(player, "That player name is already in use.");
		return 0;
	      endif
	    endfor
	    new = create($player_class, $nothing);
	    set_player_flag(new, 1);
	    new.name = name;
	    new.aliases = {name};
	    new.programmer = $player_class.programmer;
	    new.password = crypt(password);
	    new.last_connect_time = time();
	    move(new, $player_start);
	    return new;
	  endif
	elseif (strcmp(command, "QUIT") == 0)
	  boot_player(player);
	else
	  msg = $welcome_message;
	  if (typeof(msg) != LIST)
	    msg = {msg};
	  endif
	  for line in (msg)
	    if (typeof(line) == STR)
	      notify(player, line);
	    endif
	  endfor
	endif
	return 0;

   Of course, the whole point of bringing this code into the database is to
   enable easy experimentation with new facilities for un-logged-in users, such
   as multiple Guest players, friendlier coping with similarly-named players,
   provision of a `who' command, etc.
-- The network interface now copes more nicely with running out of buffer
   space for output to a player.  Before, excess output was simply dropped on
   the floor; now, it instead attempts to push it out the network socket and
   only flushes output when that doesn't work.  I was able to have a single
   command send me over 60,000 characters of output without flushing any.
-- The PREFIX and SUFFIX strings are no longer printed either for the .program
   command or for any of the lines of program input.
-- Recycled players with active connections are more promptly noticed and their
   connections closed.
-- The numeric ID associated with forked tasks is now guaranteed to be the same
   as the value of task_id() in that task when it executes.
-- The create() function now invokes the :initialize verb on the newly-created
   object before returning it.  It is not an error if there is no :initialize
   verb defined on the object.
-- Changed listinsert() and listappend() never to generate E_RANGE errors.
   Instead, the following expressions are now always equivalent:
	listinsert(list, element, index)
	listappend(list, element, index - 1)
	{@list[1..index - 1], element, @list[index..length(list)]}
-- Changed the matching algorithm for verb names so that the old behavior of
   `*' matching anything is generalized to `foo*' matching anything beginning
   with `foo'.
-- Changed eval() and set_verb_code() to require programmer permissions.
-- Added a timezone abbreviation onto the end of ctime()'s result.
-- Added min(), max(), and abs() functions.
-- The messages printed for running out of ticks and for running out of seconds
   are now disinguishable.

From pavel@arisia.Xerox.COM Fri Jun  7 17:08:22 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05118; Fri, 7 Jun 91 17:08:21 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA12483; Fri, 7 Jun 91 17:03:13 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11593>; Fri, 7 Jun 1991 17:03:08 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 7 Jun 1991 17:02:42 -0700
Message-Id: <91Jun7.170242pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 7 Jun 1991 17:02:37 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: New version of LambdaCore released

A new version of the LambdaCore database, compatible with version 1.3.0 of the
server, has been stored on
	[belch.berkeley.edu]pub/moo/LambdaMOO/LambdaCore-7Jun91.db

This was made this morning from the running LambdaMOO database, so it includes
all core-DB changes made there since early April.  In particular, the following
are noteworthy:

-- There is now a generic line-oriented text editor, with children acting as a
   verb code editor, a mail editor, and a note editor.  The new editor is more
   powerful than either the old mail room or the old program editor.

-- The @audit and @count commands now never run out of time, thanks to the
   new task scheduler in version 1.3 of the server.

-- The mail system is very much enhanced, including automatic forwarding,
   mailing lists, message inclusion in replies, etc.

-- The number of objects holding useful utility verbs has just about doubled.

-- The @classes command now produces useful output and can be easily customized
   by the wizards.

I'm sure that there are many, many other changes of equal or greater import
that I'm just forgetting; it gets that way when you only release a new version
after two months... :-)

The LambdaCore database commands are, as usual, more-or-less completely
documented in the online help system.  Unfortunately, also as usual, the
various programming interfaces are only documented by (all too scarce) comments
in the code.

	Pavel/Haakon/Lambda

From pavel@arisia.Xerox.COM Fri Jun  7 17:14:38 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05142; Fri, 7 Jun 91 17:14:37 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA12555; Fri, 7 Jun 91 17:08:52 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11593>; Fri, 7 Jun 1991 17:08:47 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 7 Jun 1991 17:08:30 -0700
Message-Id: <91Jun7.170830pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 7 Jun 1991 17:08:24 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: New Version of the LambdaMOO Programmer's Manual

A new version of the LambdaMOO Programmer's Manual, documenting version 1.3 of
the LambdaMOO server, has been stored on
	[belch.berkeley.edu]pub/moo/LambdaMOO/ProgrammersManual.*

As before, the source is in Texinfo format and both compressed and uncompressed
versions of the Postscript output are available.  Unfortunately, also as
before, there still does not exist a truly plain-text version.  I am given to
understand that the maintainer of the conversion software has recently returned
from a long trip abroad and that he will soon be addressing my bug reports...

This version of the manual, in addition to documenting the new features in
version 1.3.0 of the server, also finally includes the last chapter, `Server
Commands and Database Assumptions', completely documenting the built-in
commands and every way in which the server depends upon a specific verb and/or
property in the database.  Those trying to fully understand a given database
now have a fair shot at it.

	Pavel/Haakon/Lambda

From jb7w+@andrew.cmu.edu Sat Jun  8 21:01:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <jb7w+@andrew.cmu.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA06568; Sat, 8 Jun 91 21:01:44 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA21788; Sat, 8 Jun 91 20:54:16 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11653>; Sat, 8 Jun 1991 20:54:11 PDT
Received: from andrew.cmu.edu ([128.2.11.131]) by alpha.xerox.com with SMTP id <11657>; Sat, 8 Jun 1991 20:51:33 PDT
Received: by andrew.cmu.edu (5.54/3.15) id <AA08901> for moo-cows@xerox.com; Sat, 8 Jun 91 23:49:47 EDT
Received: via switchmail; Sat,  8 Jun 91 23:49:46 -0400 (EDT)
Received: from monsoon.ucc.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.AcIOHuG00WAxM0SWgw>;
          Sat,  8 Jun 91 23:48:15 -0400 (EDT)
Received: from monsoon.ucc.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr24/jb7w/.Outgoing/QF.IcIOHqO00WAx0UgU4M>;
          Sat,  8 Jun 91 23:48:06 -0400 (EDT)
X-Ns-Transport-Id: 08002008D0FD000C32C6
Message-Id: <Added.IcIOJOO00Ui3EWl04o@andrew.cmu.edu>
Date: 	Sat, 8 Jun 1991 20:48:05 PDT
From: Joseph Gerard Behrmann <jb7w+@andrew.cmu.edu>
To: moo-cows.PARC@xerox.com
Subject: I need a binary...


Ok, with the new release of the server, I once again need a copy of the
pmax_3 system type binary for it, my stupid compilers here can't handle
the code, they barf because of the prototyping and because stdlib.h
doesn't exist here (don't ask me why, its a long story).  Anyway, I would
appreciate it if someone would compile it for me on a pmax and provide me
with a copy of it (mail a uuencoded version, or an ftp site, etc.) as that
would be much easier than me trying to go through the whole code trying to
change it.  If you know where the program unproto (I think that's it) is
located, that would help also.  Please help, I am trying to work on
programming moo and the new server would really be helpful, thanks.

Joe
jb7w+@andrew.cmu.edu

From pavel@arisia.Xerox.COM Mon Jun 10 11:30:01 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA08554; Mon, 10 Jun 91 11:29:59 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA10936; Mon, 10 Jun 91 11:22:00 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11540>; Mon, 10 Jun 1991 11:21:49 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 10 Jun 1991 11:21:05 -0700
In-Reply-To: <9106071835.AA09678@Neon.Stanford.EDU>
Message-Id: <91Jun10.112105pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 10 Jun 1991 11:21:00 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: ticks and associativity

Roger Crew writes:
> It seems strange that 
> 
>     cond ? thenclause | elseclause 
> 
>     return a && b;
> 
> each cost one tick while the corresponding conditional statements
> 
>     if(cond) 
>       thenclause; 
>     else 
>       elseclause; 
>     endif
> 
>     if(a) 
>       return a; 
>     else 
>       return b; 
>     endif 
> 
> cost nothing.  While one could go through and try to decide which
> sorts of expressions should be charged and which shouldn't, I would
> say that the easiest way to restore equity would be to have
> if(...) statements be charged 1 tick.  Seeing as you're already doing
> this with for/while loops, this shouldn't be too radical a proposal.  

I suppose that I have no objection to doing this (though I would make each `if'
and `elseif' cost a tick), but is it really worth it?

> Then, I noticed that 0&&0&&0&&0&&0 costs 4 ticks, yet the server
> shouldn't have to do any real work beyond evaluating the first 0.  
> The real problem here is that left associativity causes this to parse as 
> (0&&0&&0&&0)&&0.  Given their short-circuiting behavior, && and || 
> should really be right-associative (i.e., parse as 0&&(0&&0&&0&&0)).

Dear me.  Of course.  This will be fixed in the next release.

> For that matter, as long as we're messing with associativity, 
> ?| should also be right-associative since a natural thing to want to do is
> 
>    cond1 ? then1 | cond2 ? then2 | cond3 ? then3 | otherwise
> 
> Contrast this with the left associative
> 
>    cond1 ? bool1t | bool1f ? bool2t | bool2f ? thenclause | elseclause
> 
> which isn't even readable without the parentheses.

I decided to make ?| non-associative, since any combination of uses is visually
ambiguous:

   (cond1 ? then1 | (cond2 ? then2 | cond3)) ? then3 | otherwise

I would much rather force the programmer to parenthesize such expressions (or,
better, not write them).

> Just out of curiosity, how much effort is involved in dumping a fully
> parenthesized db (i.e., as a prelude to making a parser change)?

The database is already dumped fully-parenthesized.  I'd like to credit this to
my enormous foresight, but actually it was a result of an earlier change to
operator precedences.

	Pavel

From pavel@arisia.Xerox.COM Tue Jun 11 09:46:06 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA11970; Tue, 11 Jun 91 09:46:04 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA27796; Tue, 11 Jun 91 09:36:02 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11645>; Tue, 11 Jun 1991 09:35:59 PDT
Received: by lambda.parc.xerox.com id <58369>; Tue, 11 Jun 1991 09:35:40 -0700
Message-Id: <91Jun11.093540pdt.58369@lambda.parc.xerox.com>
Date: 	Tue, 11 Jun 1991 09:35:27 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Bug in LambdaCore-7Jun91.db

A few folks have noticed a bug in the recently-released core database: the
.help property on $mail_editor, $verb_editor, and $note_editor points to a
non-existant object.  The fix is simple:

	;$mail_editor.help = $verb_editor.help = $note_editor = $editor_help
	;$generic_editor.help = $editor_help

A new version of the core db with this fix applied has been stored on

	[belch.berkeley.edu]pub/moo/LambdaMOO/LambdaCore-11Jun91.db

(For the trivia buffs among you, that makes three releases of LambdaCore dated
the 11th of some month...)

	Pavel

From @vaxb.acs.unt.edu:cluther@sonne.cnns.unt.edu Fri Jun 14 08:55:12 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@vaxb.acs.unt.edu:cluther@sonne.cnns.unt.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03159; Fri, 14 Jun 91 08:55:09 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA03513; Fri, 14 Jun 91 08:48:37 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11644>; Fri, 14 Jun 1991 08:48:35 PDT
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11644>; Fri, 14 Jun 1991 08:48:03 PDT
Received: by sonne (4.1/1.36)
	id AA08021; Fri, 14 Jun 91 10:45:18 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD000C70D6
Message-Id: <9106141545.AA08021@sonne>
Date: 	Fri, 14 Jun 1991 08:45:16 PDT
From: cluther%sonne.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@arisia.Xerox.COM (Moo Cows)
Subject: Ok, so where is it.

I am relegated to the tedium of @showing every object in the core, then
@listing every verb to learn about them?

Or, has somebody stashed away some reasonable documentation about the core and
the core verbs (no, not help stuff -- real documentation)?

And, no, I don't want the Moo PL docs...I'm looking for the *core* docs.

Thanks!

-- 
Clay W. Luther                  cluther@sonne.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               Void where prohibited by law.

From pavel@arisia.Xerox.COM Fri Jun 14 09:42:58 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03348; Fri, 14 Jun 91 09:42:57 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA06210; Fri, 14 Jun 91 09:36:23 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11654>; Fri, 14 Jun 1991 09:36:18 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 14 Jun 1991 09:35:56 -0700
In-Reply-To: <9106141545.AA08021@sonne>
Message-Id: <91Jun14.093556pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 14 Jun 1991 09:35:53 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: cluther%sonne.cnns.unt.edu@vaxb.acs.unt.edu
Cc: moo-cows@arisia.Xerox.COM
Subject: Re: Ok, so where is it.

Unfortunately, I have not yet had anywhere near enough time to document the
LambdaCore.  Fortunately, a group at HP led by `blip' has done quite a bit of
work in this area, though they're not yet ready to release their document.
Until then, I'm afraid that you're stuck with `@list', `@show', and `say' (to
ask other programmers and wizards).

Good luck!

	Pavel/Haakon/Lambda (always open to questions)

From crew@Neon.Stanford.EDU Fri Jun 14 14:57:05 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@Neon.Stanford.EDU>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA04343; Fri, 14 Jun 91 14:57:02 PDT
Received: from Neon.Stanford.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA25074; Fri, 14 Jun 91 14:49:30 -0700
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA11856; Fri, 14 Jun 91 14:49:04 -0700
Message-Id: <9106142149.AA11856@Neon.Stanford.EDU>
In-Reply-To: Your message of Fri, 14 Jun 91 09:35:53 -0700.
             <91Jun14.093556pdt.58369@lambda.parc.xerox.com> 
X-Date: Fri, 14 Jun 91 14:41:49 PST
Date: Fri, 14 Jun 91 14:48:59 -0700
From: Roger Crew <crew@Neon.Stanford.EDU>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Ok, so where is it. 

A few nights ago, I dumped out the LambdaMOO help tree, permuted it
into a vaguely depth-first order and left it on belch.  

Check out belch.berkeley.edu:pub/moo/LambdaMOO/helptree.txt

At some point I may get around to turning it into emacs info nodes so
that the menus and cross references would actually work as such...

	Roger  (a.k.a. Rog@LambdaMOO)

From chughes@maths.tcd.ie Sat Jun 15 14:35:14 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <chughes@maths.tcd.ie>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05952; Sat, 15 Jun 91 14:35:11 PDT
Received: from mcsun.EU.net by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA03364; Sat, 15 Jun 91 14:29:01 -0700
Received: by mcsun.EU.net via EUnet;
	id AA05918 (5.65a/CWI-2.94); Sat, 15 Jun 91 23:28:56 +0200
Received: from swift by macneill.macneill.cs.tcd.ie id aa28069;
          15 Jun 91 22:11 GMT
Received: from lanczos.maths.tcd.ie by cs.tcd.ie with PMDF#10597; Sat, 15 Jun
 1991 22:03 +0100
Received: from lanczos by lanczos.maths.tcd.ie  Via SMTP (FibreOptic) id
 aa29808; 15 Jun 91 22:03 BST
Message-Id: <9106152203.aa29808@lanczos.maths.tcd.ie>
X-Envelope-To: moo-cows@arisia.xerox.com
Date: Sat, 15 Jun 91 22:03:55 +0100
From: Conrad Hughes <chughes@maths.tcd.ie>
Cc: moo-cows@arisia.Xerox.COM
Subject: LambdaMOO 1.3.0, task limits..


The new server is almost twice as memory-efficient as 1.2 - thanks
very much Mr Curtis! (The MOO here had to shut down two days before
the new server arrived because of a combination of the memory leaks
and its fundamental inefficiency with memory; back up now :-)

What I'm writing about is task limits - does anybody else out there
feel a per-player task limit would be worthwhile? I would really
like such a facility to be implemented (in similar manner to the
object quota system) if only to protect the machine that I've got
MOO running on.. It's squashed into a nearly-full disk partition,
and if anybody either accidentally or deliberately runs a program
such as:
	while(1) fork(1) this:thisverb(); endfork endwhile
..memory usage starts growing at a rate of 200k/second.. And on a
SPARCstation SLC with 8Mb of RAM this just isn't a reasonable
proposition :-( I've hacked in a flat limit of 100 forked tasks
again to protect against this, but would much prefer to have a per-
player quota system running, so that I could give programmers who
are implementing new sections of the VR the number of tasks they
need, and players and less `important' programmers a lower limit
which will still fit them safely..

Comments?

Conrad

From mjp@hplb.hpl.hp.com Mon Jun 17 04:14:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <mjp@hplb.hpl.hp.com>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA07254; Mon, 17 Jun 91 04:14:51 PDT
Received: from hplb.hpl.hp.com by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA29972; Mon, 17 Jun 91 04:04:31 -0700
Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Mon, 17 Jun 91 12:00:15 +0100
Received: by prudence with SMTP
	(15.11/15.6+ISC) id AA25055; Mon, 17 Jun 91 09:10:07 bst
Message-Id: <9106170810.AA25055@prudence>
Date: Mon, 17 Jun 91 09:10:05 BST
From: Mike Prudence <mjp@hplb.hpl.hp.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Ok, so where is it.

Hi Moo-Cows.

Recently cluther%sonne.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther) said:

> Or, has somebody stashed away some reasonable documentation about
> the core and the core verbs (no, not help stuff -- real
> documentation)?

Well, you could be in luck.  I was going to reply by private e-mail to
this, as the docs I have are by no means complete, finished or even
correct !! But I guess there will be more than one person on this
mailing list who will want an answer to the same question.

We have a small group here at Hewlett Packard that have been working
to convert our MUCK to a MOO.  We came to MOO completely cold, so I
started to work on some docs for the 1.2 Core databse, simply because
you can't effectively write any programs if you don't understand the
core.

This is a separate effort from the work that Lambda has said he will
be doing, and is probably not a quarter as good as any manual that
Lambda might produce.  However, it does almost exist.

At the moment, we are in a flurry trying to work out what is going on
in the 1.3 database.  Lots of things have changed, and lots of things
have been added, although the basis seems to be the same.  

If you folks can stand to wait for a few more weeks, I would feel
happy giving out copies (with Lambda's approval, of course) of this
manual, on the understanding that any errors get fed back to me so
that I can correct them.

However, at the moment, the manual is in no fit state to be read by
anyone who wants to understand what it is saying :)

I'll keep you posted.

Cheers,

Mike

mjp@hplb.hpl.hp.com     "Anagrams(1) : Hewlett Packard => pedal that wreck"


From crew@neon.stanford.edu Mon Jun 17 19:23:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA09715; Mon, 17 Jun 91 19:23:37 PDT
Received: from Neon.Stanford.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA13615; Mon, 17 Jun 91 19:13:21 -0700
Received: from Boole.Stanford.EDU by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA20920; Mon, 17 Jun 91 19:13:18 -0700
Message-Id: <9106180213.AA20920@Neon.Stanford.EDU>
Date: Mon, 17 Jun 91 16:10:12 PST
From: Roger Crew <Crew@CS.Stanford.EDU>
To: moo-cows@arisia.Xerox.COM
Subject: intercepting builtin functions that change the db

Background observations:

(*) Bad things happen if a player chparents him/herself to a nonplayer
class that is missing verbs/properties that are usually expected of
players (e.g., .password, .home...).  Rather than have to rewrite all
code dealing with players so as to check for the existence of standard
player verbs/properties before calling/accessing them, it would be
much nicer to be able to intercept and prohibit silly chparent calls.

(*) There are now so many players that an old-style match_player now
takes >18000 ticks.  Thus we needed an incremental scheme.  The problem 
is keeping this up to date whenever new players are created/recycled/toaded/etc

(*) The recycle verb on a class can always be overridden.

(*) Isn't it odd that ownership quota is hardwired into the server?

(*) It is not always desirable to have readability imply fertility for objects.

(*) #0 doesn't have enough verbs on it :-)

Status quo:
Straight from the programmers manual, here's a list of those builtins 
that call db verbs:

    <new connection>
     -> #0:do_login_command(...)
     -> <connect>
     -> p.location:confunc(p)
     -> p:confunc()
    boot_player(p) 
     -> p:disfunc()
     -> p.location:disfunc(p)
     -> <disconnect>
    create(c,p)
     -> <create> => o
     -> o:initialize()
    recycle(o)
     -> o:recycle()
     -> <recycle>
    move(o,l)
     -> l:accept(o)
     -> <move>
     -> o.location:exitfunc(o)
     -> l:enterfunc(o)

Proposal:
The idea is to make this a bit more comprehensive and extendable.
Below, what's marked with -> is what the server would do followed by
suggested (pseudo)code for the new verbs in LambdaCore.


    <startup>
     -> #0:startup
            anything that needs to happen in the very first task.

    shutdown(...)
     -> #0:shutdown
            who=caller_perms();
            msg=tostr("*** Server shutdown by ",who.name,"(",who,"): ",@args); 
            for p in (connected_players()) 
              p:tell(msg);
            endfor
     -> <halt>

    <new connection> 
     -> #0:before_login(...) => p or 0
            all of the current :do_login_command code
     -> <connect p>
     -> #0:after_login(p)
	    p.location:rconfunc(p)
	    p:pconfunc()

    boot_player(p)
     -> #0:boot_player(p)
	    p:pdisfunc()
	    p.location:rdisfunc(p)
     -> <disconnect p>

    create(c,own,..)
     -> #0:before_create(c,own,...) => 1 or an error code
	    if(own.ownership_quota<=0)
              return E_QUOTA;
            elseif(!c:accept_custody(#-1,own,...))
              return E_NOKIDS;
            else
              own.ownership_quota--;
              return 1;
            endif
     -> <create c,own> => o
     -> #0:after_create(o,...)
	    o:initialize(...)
            c:adopt(o,#-1,...)
	    return o;

    recycle(o)
     -> #0:recycle(o)
	    o:recycle()
	    p.ownership_quota++
     -> <recycle>

    move(o,to)
     -> #0:before_move(o,to) => 1 or an error code
	    return to:accept(o) || E_NACC;
     -> <move>
     -> #0:after_move(o,from)
            if(o.location!=from) 
              from:exitfunc(o,to)
  	      if(o.location==to)   
                to:enterfunc(o,from)
            endif

    chparent(o,new,..) 
     -> #0:before_chparent(o,new,...) => 1 or an error code
	    return new:accept_custody(o,o.owner,...) || E_NOKIDS;
     -> <chparent>
     -> #0:after_chparent(o,new,ex_parent,...)
	    ex_parent:relinquish(o,new,...)
	    new:adopt(o,ex,...)

    set_player_flag(p,f)
     -> #0:before_set_player_flag(p,f)
	    if(!f) p:im_sorry_im_sorry_really_i_ll_be_good_now(); endif
     -> <set flag to f>
     -> if(!f) boot_player(p); endif
     -> #0:after_set_player_flagf(p,f)
	    if(f) p:thank_you(); endif

The `...' arguments to #0:*_create/:*_chparent/:shutdown are supplied by the
caller of the built-in function and passed verbatim to the corresponding 
#0 verbs (which can in turn do whatever they want, of course).

A variation on this would be to combine the various #0:before/after_foo 
functions.  This would entail one more builtin do_it() which would be 
recognized only in a verb called directly by a builtin and would return true according as the raw built-in operation succeeded.  
In this scheme, we would, e.g., do move() as

    move(o,to)
     -> #0:move(o,to)
            from=o.location;
            if(to==from)      return 0;      endif
	    if(!to:accept(o)) return E_NACC; endif
            if(!(d=do_it()))  return d;      endif
            if(o.location!=from) 
              from:exitfunc(o,to)
  	      if(o.location==to)   
                to:enterfunc(o,from)
            endif
            return 0;

and likewise for create(), chparent(), set_player_flag(),...
The one disadvantage to this is that here, errors like E_NACC and E_RECMOVE
would only be returned and not raised.

  - - - - - - -

Incidentally, note that error codes like E_QUOTA, and E_NACC would no longer have any intrinsic meaning to the server, so why not move these into the core as well?  I.e., have the following builtins

    add_error(name,message[,number]) => number of new error if successful
    delete_error(number)             => true or E_INVARG
      these two would require wizard perms and would not be able to remove
      the server's builtin error codes/messages.

    toerr(number or string) 
     => corresponding error code 
     e.g., toerr(0)=>E_NONE, 
           toerr(1)=>E_TYPE, 
           toerr("VERBNF")=E_VERBNF)
           toerr(34)=>an error value whose tonum() is 34
           tostr(toerr(34)) => "User-defined error 34";

And then we put the following lines in #0:startup()

    add_error("NACC","Move refused by destination")
    add_error("QUOTA","Object ownership quota exceeded")
    add_error("NOKIDS","Parentage refused")

Having toerr() available also means one doesn't have to be constantly
scrounging for error codes that one isn't completely certain aren't
being used for something else.  Given add/delete_error, it would be a
simple matter to have a core verb that creates and registers new error
messages on the fly.

From lamping@arisia.Xerox.COM Tue Jun 18 11:41:14 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lamping@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA11319; Tue, 18 Jun 91 11:41:12 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA00624; Tue, 18 Jun 91 11:29:51 -0700
Received: from navarro.parc.xerox.com ([13.2.18.19]) by alpha.xerox.com with SMTP id <11822>; Tue, 18 Jun 1991 11:29:41 PDT
Received: by navarro.parc.xerox.com id <36097>; Tue, 18 Jun 1991 11:29:56 -0700
Fake-Sender: lamping@parc.xerox.com
In-Reply-To: Roger Crew's message of Mon, 17 Jun 91 16:10:12 PST <9106180213.AA20920@Neon.Stanford.EDU>
Message-Id: <91Jun18.112956pdt.36097@navarro.parc.xerox.com>
Date: 	Tue, 18 Jun 1991 11:29:53 PDT
From: John Lamping <lamping@parc.xerox.com>
Sender: John Lamping <lamping@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: intercepting builtin functions that change the db

A lot of Rog's intercepts could be handled without adding more db
interecpts by making some fields protected so that standard wizard code
must always be invoked to do them.  Specifically: move(), recycle(),
chparent(), and set_player_flag() could all be handled that way.  That is,
mortals must always call wizard verbs to do do those things, and the wizard
verbs make all the calls that Rog suggests.

This does require one change, and suggests another.

First, wizard code needs to be able to protect itself from errors
(including running out of time) in code it calls, so that, for example,
when the wizard version of move() calls :accept(), it can keep running even
if :accept runs out of time or has an error or something.  (Haakon has
already suggested something like this.)

The second change would be for backwards compatibility and general
convenience: be able to abbreviate #0:xxx(...) as xxx(...).  This would let
functions migrate into (and out of) the database without having to do lots
of revision of existing code.  Some of the stuff currently in $yyy:xxx()
could be promoted to #0 for shorter and prettier access.  #0 would be a
place to put things that aren't supposed to be overriden.

From crew@Neon.Stanford.EDU Tue Jun 18 19:07:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@Neon.Stanford.EDU>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA12687; Tue, 18 Jun 91 19:07:51 PDT
Received: from Neon.Stanford.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA03918; Tue, 18 Jun 91 18:59:36 -0700
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA11548; Tue, 18 Jun 91 18:59:11 -0700
Message-Id: <9106190159.AA11548@Neon.Stanford.EDU>
In-Reply-To: Your message of Tue, 18 Jun 91 11:29:53 -0700.
             <91Jun18.112956pdt.36097@navarro.parc.xerox.com> 
Date: Tue, 18 Jun 91 18:59:07 -0700
From: Roger Crew <crew@Neon.Stanford.EDU>
To: moo-cows@arisia.Xerox.COM
Subject: Re: intercepting builtin functions that change the db 

>   making some fields protected so that standard wizard code
>   must always be invoked to do them.  Specifically: move(), recycle(),
>   chparent(), and set_player_flag() could all be handled that way.  

While I agree move() could certainly be done this way, i.e., making
.location and .contents into honest properties (yay!), the jury is
still out on making playerness a field, and recycle() and chparent()
have server-intrinsic raw actions (e.g., creation/destruction of
objects, modification of the parent hierarchy,...), that I don't 
believe can easily or in fact should be moved into the db. 

Or, by "making some fields protected," did you merely mean
making the raw builtin functions accessible to wizards only?  
In that case, create(), boot_player() and shutdown() can also 
be done this way as well.

I'll agree that changing the current builtin calls to verb calls
and having the builtin functions be reduced to raw server actions
accessible to wizards only makes more sense than putting in lots of 
intercepts and having do_it() refer to the raw action.

>   The second change would be for backwards compatibility and general
>   convenience: be able to abbreviate #0:xxx(...) as xxx(...).  

I think it is important to distinguish between verb calls and 
builtin calls, if for nothing else than programmers need a clear 
sense of what's immutable and what isn't (i.e., where the rug is
most likely to be pulled out from under them...:-)

I also mislike the idea of having the interpretation of e.g.,
chparent() depend on the ownership of the verb in which it occurs,
that is having chparent() mean the raw chparent() if we're wizardly 
and #0:chparent() otherwise.  I had enough trouble with a previous
version of the server where move() meant different things depending
on the wizardliness of the caller (...does :accept() get called?).
Ideally, the *only* consequence of changing a verb from being
wizard-owned to being non-wizard-owned should be that in the
non-wizard case you may bomb out at some point with an E_PERM.

Anyway, suppose the wizard-owned verb wants to be recursive?

I would much prefer abbreviating #0:xxx(...) to $xxx(...).  
Nor is there danger of confusion with the usual #0.xxx === $xxx usage 
since #0.xxx(...) is a syntax error.

As for backwards compatibility, I'd like to think it would be a simple
matter to egrep the db offline changing all occurences of [^:]move()
to $move().  

Using different names for the new raw builtins would also avoid confusion.

There's also a 3rd change that would be necessary, namely, if $move()
is to be a completely in-db verb we really do need the notion of
user-defined errors as I described previously, but also we need 
the ability to actually raise an error like E_NACC or E_RECMOVE
(i.e., cause +d code to bomb with a stack trace) as opposed to 
merely returning them.  I seem to recall this was in the works, too.

Putting everything together produces the following, much shorter list
of intercepts

    <server start>
      -> $startup()

    <login attempt>
      -> $login(cmdline)

    <command line parser>
      -> $location(player)
      -> <verb>(...)

and redefined raw builtin functions

  login(p)  -- changes the current connection's associated player to p
               error if there is no current connection (i.e.,forked task).
               return value indicates if this is a redirection.
  logout(p) -- close connection for player p   [replaces boot_player()]
  new_player(p) -- makes p into a player       [replaces set_player_flag(,1)]
  ex_player(p)  -- makes p into a non-player   [replaces set_player_flag(,0)]
                   error if p is connected.
  create(c,own) -- create object, initialize inherited properties
  recycle(o)    -- destroy object
  chparent(o,p) -- wipe non-common properties and change the parent
  immediate_death() -- kill all tasks and halt the server [replaces shutdown()]
                       Note that wizards would be highly encouraged to use the
                       more graceful $shutdown() that would first run 
                       $boot_player() on everyone.

	Roger

From sfwhite@watcgl.waterloo.edu Tue Jun 18 20:36:00 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA12798; Tue, 18 Jun 91 20:35:55 PDT
Received: from watcgl.waterloo.edu by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA04511; Tue, 18 Jun 91 20:27:46 -0700
Received: by watcgl.waterloo.edu
	id <AA23331>; Tue, 18 Jun 91 23:27:41 -0400
Message-Id: <9106190327.AA23331@watcgl.waterloo.edu>
Date: Tue, 18 Jun 91 23:27:41 -0400
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: moo-cows@arisia.Xerox.COM
Subject: Re: intercepting builtin functions that change the db

there's an alpha version of moo 2.0 on belch.berkeley.edu in
the /pub directory.  (this is the original ghondMOO, not lambda).

i've actually been sitting on this for about 3 months, but haven't
had any time to work on it.  it has a few known bugs, and quite
a few interesting additions:

* _no_ builtin commands.
* no builtin verbs
* no built-in properties (although there are six which are required,
  they are real properties)
* properties are typed and permed and owned at the source, ie., with
  the property definition, rather than the property.
* most of the parser is rewritten in MOO
* the player connection & creation stuff is in MOO

probably some more things, which i forget.  there's also a LaTeX
document describing it.

known bugs:  chparent() is broken.

-- stephen/ghond

From @vaxb.acs.unt.edu:cluther@sonne.cnns.unt.edu Wed Jun 19 14:04:50 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@vaxb.acs.unt.edu:cluther@sonne.cnns.unt.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA14211; Wed, 19 Jun 91 14:04:47 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA16179; Wed, 19 Jun 91 13:57:45 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11765>; Wed, 19 Jun 1991 13:57:38 PDT
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11526>; Wed, 19 Jun 1991 11:58:53 PDT
Received: by sonne (4.1/1.36)
	id AA08828; Wed, 19 Jun 91 13:55:54 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD000CA36F
Message-Id: <9106191855.AA08828@sonne>
Date: 	Wed, 19 Jun 1991 11:55:52 PDT
From: cluther%sonne.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@arisia.Xerox.COM (Moo Cows)
Subject: Troubles with Verb Args

I need to create a verb, @addskill, that accepts two arguments, a skill and a
base.  These are formed into an ordered pair and appended to a property list.

For instance, @addskill foo bar, would create the pair {"foo","bar"}.

How do I set my verbs arguments to handle this?

-- 
Clay W. Luther                  cluther@sonne.cnns.unt.edu
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               Void where prohibited by law.

From ken@imsa.edu Thu Jun 20 23:28:57 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA18214; Thu, 20 Jun 91 23:28:52 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA09341; Thu, 20 Jun 91 23:22:18 -0700
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <12122>; Thu, 20 Jun 1991 23:22:15 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA00442; Fri, 21 Jun 91 01:22:28 CDT
Message-Id: <9106210622.AA00442@imsa.edu>
Date: 	Thu, 20 Jun 1991 23:22:28 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: moo-cows@arisia.Xerox.COM
Subject: logout actions, or rather, lack thereof

    I've been experimenting with a new player class lately, and I've
hit a slight snag.  Essentially, the problem is that using this player
class may, at times, cause the name of the player to be altered.  I
nearly gave myself a cardiac arrest, when I tried to log onto Lamda
and got the 'Either that player doesn't exist...' message, until I
realized that it was because my name had changed and the client I was
using was trying to log me in with my old name.
    I decided that this was a bug as opposed to a feature, and
promptly attempted to fix it.  I figured I'd just write a @quit
attached to my player class that would check some properties, to see
if the name was what it should be before logging out (i.e. whatever
your client expects it to be), and if it wasn't it would take an
apropriate action to make it so.
    This wasn't even the problem.  The problem came later when I tried
to do pass the @quit up to #6:@quit, after I'd done my check and
possibly taken an action to reset the name.  When I tested it, it
promptly died with a 'verb not found' error, right on the pass.  After
a few moments, I realized what was happening.  #6:@quit is !x, so it
is not within the namespace for being executed from within my verb.
This means that currently *it is impossible to automatically perform
any actions before you quit, unless you are a wizard*.

    As I see it, there several possible solutions to this problem.
I'll list them in the order of 'correctness', as I see it (of course,
G7 will probably disagree :-).

    1) Make it so that !x verbs can still be called using pass();.  To
me this makes the most sense, and would allow sensible things to take
place (such as what I have described here).

    2) Add a 'logout' verb that is called right before the player gets
booted, to perform any cleanup operations (like the one I described
above).  (If this path is chosen, a 'login' verb might also be
apropriate.)  I don't particularly like this solution, because it
seems to me to be (watch for G7 flames on this point :-) a kludgey way
to get around the problem.  Also, other similar problems may crop up
later that could be fixed by using my first suggestion, which would
then also have to be special cased (yech).

    2) Get some wizard to own my @quit, so that I can put a
boot_player(player); in it.  (No, this is not a whiny 'please help me
Mr./Ms./Mrs. Wizard' note; if I have to do it this way, I'll
personally ask a wizard about it.)  I don't like this, because I think
it's avoiding the issue.  (Not to mention the increase in wizard work
load.)  Again, I think other similar problems might crop up, and this
doesn't provide a solution to them the way that my first suggestion
does.

    Comments and criticisms welcome; flames shall be duly returned.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/ Kenneth C Schalk, aka ///"Is conciousness just a special form of ///
\ Xorian|Darkman on MUDs \\  hallucination?"--Frank Herbert        \\\  //-\
////////////////////////////////////////////////////////////////////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All opinions expressed are those \\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.                   \\
//////////////////////////////////////////////////////////////////////


From ken@imsa.edu Fri Jun 21 01:07:54 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA18430; Fri, 21 Jun 91 01:07:51 PDT
Received: from imsasun.IMSA.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA09745; Fri, 21 Jun 91 01:02:02 -0700
Received: by imsa.edu (4.0/SMI-4.0)
	id AA00572; Fri, 21 Jun 91 03:02:27 CDT
Message-Id: <9106210802.AA00572@imsa.edu>
Date: Fri, 21 Jun 91 03:02:27 CDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: ken@imsa.edu, moo-cows@arisia.Xerox.COM
Subject: Re:  logout actions, or rather, lack thereof

    I may have to (unfortunately, and unwillingly) rescind my earlier
suggestion.  I ahve been talking with Grump for some time now about
whether or not this could possibly open up any security holes.  For
the most part, we found none.  However, under certain circumstances,
if one cahnges the value of the 'this' variable, the !x passing could
be misused.

    For example, if I were to create a child of some other player, and
add a @mail verb to it, in which I did something like:

this=parent(this);
pass();

I could potentially read that persons mail.  There may be ways to fix
this (without rewriting large numbers of verbs), but I'm not sure, as
I'm not familiar with the internals of MOO.  In spite of this
potential problem, I still think that passing to !x verbs is the best
solution, if it can be made safe.

    Ken/Xorian[s]



From asun@ocf.Berkeley.EDU Fri Jun 21 07:05:16 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <asun@ocf.Berkeley.EDU>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA18890; Fri, 21 Jun 91 07:05:13 PDT
Received: from tempest.Berkeley.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA12283; Fri, 21 Jun 91 06:58:59 -0700
Received: by tempest (5.61/CHAOS)
	id AA01698; Fri, 21 Jun 91 06:55:39 -0700
Message-Id: <9106211355.AA01698@tempest>
In-Reply-To: Kenneth C. Schalk's message of Thu, 20 Jun 1991 23:22:28 PDT <9106210622.AA00442@imsa.edu>
Date: Fri, 21 Jun 91 06:55:39 -0700
From: a sun <asun@ocf.Berkeley.EDU>
To: ken@imsa.edu
Cc: moo-cows@arisia.Xerox.COM
Subject: logout actions, or rather, lack thereof

       2) Add a 'logout' verb that is called right before the player gets
   booted, to perform any cleanup operations (like the one I described
   above).  (If this path is chosen, a 'login' verb might also be
   apropriate.)  I don't particularly like this solution, because it
[...]

this is already done. :disfunc() is called on logout, and :confunc()
is called on login. i've never thought that the use of verbs was a
kludge. in fact, i prefer manipulation of characteristics through
verbs rather than modification of properties (i.e., :description() and
:title()). i do think that :title() isn't used enough though. i have a
feeling that all the problems you're having with your polymorphing
player would be solved if :title() were used by the common verbs and
people used :title() instead of player.name when creating verbs. i
guess this stems from my belief that .name is somewhat inviolate. when
one polymorphs, the nature and the appearance are altered, but the
name remains. i imagine that it might be possible to polymorph
yourself to another character only to discover that you can't
polymorph back.

-a

From asun@ocf.berkeley.edu Fri Jun 21 07:54:25 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <asun@ocf.berkeley.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA18975; Fri, 21 Jun 91 07:54:22 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA12827; Fri, 21 Jun 91 07:47:51 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11641>; Fri, 21 Jun 1991 07:47:33 PDT
Received: from tempest ([128.32.234.28]) by alpha.xerox.com with SMTP id <11680>; Fri, 21 Jun 1991 07:46:40 PDT
Received: by tempest (5.61/CHAOS)
	id AA01723; Fri, 21 Jun 91 07:42:23 -0700
X-Ns-Transport-Id: 08002008D0FD000CBCB8
Message-Id: <9106211442.AA01723@tempest>
Date: 	Fri, 21 Jun 1991 07:42:23 PDT
From: a sun <asun@ocf.berkeley.edu>
To: moo-cows.PARC@xerox.com
Subject: just a reminder


MOO-Cows is a mailing list for primarily server issues. questions
dealing with the LambdaDB will often receive more feedback if the
internal LambdaMOO mailing lists are used, help is consulted, or
wizards/other LambdaMOO programmers are asked. in particular,
*Core-DB-Issues might be of interest for those seeking modification of
the DB on Lambda.

-a
(soapboxing for a day)

From nop@att1.Mankato.MSUS.EDU Fri Jun 21 09:04:31 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <nop@att1.Mankato.MSUS.EDU>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19109; Fri, 21 Jun 91 09:04:27 PDT
Received: from ATT1.Mankato.MSUS.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA13513; Fri, 21 Jun 91 08:57:47 -0700
Received:  by att1.Mankato.MSUS.EDU (5.59/25-eef)
	id AA14801; Fri, 21 Jun 91 10:57:18 CDT
Message-Id: <9106211557.AA14801@att1.Mankato.MSUS.EDU>
In-Reply-To: a sun's message of Fri, 21 Jun 91 06:55:39 -0700 <9106211355.AA01698@tempest>
Date: Fri, 21 Jun 91 10:57:18 CDT
From: Jay A. Carlson <nop@att1.Mankato.MSUS.EDU>
To: asun@ocf.Berkeley.EDU
Cc: ken@imsa.edu, moo-cows@arisia.Xerox.COM
Subject: logout actions, or rather, lack thereof


> this is already done. :disfunc() is called on logout, and :confunc()
> is called on login. i've never thought that the use of verbs was a
> kludge. in fact, i prefer manipulation of characteristics through
> verbs rather than modification of properties (i.e., :description() and
> :title()).

This isn't really related, but: 

I agree with you.  But for security reasons, often verbs must be
kludged to depend on secure properties.  If verbs had something like
the 'c' bit to stop overriding, a lot of secured objects would become
much simpler.

LambdaMOO would act more OO if verbs could be secured as well as
properties, IMHO.


From pavel@arisia.Xerox.COM Fri Jun 21 10:43:04 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19518; Fri, 21 Jun 91 10:43:02 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA14926; Fri, 21 Jun 91 10:33:19 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11670>; Fri, 21 Jun 1991 10:33:13 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 21 Jun 1991 10:32:56 -0700
In-Reply-To: <9106210622.AA00442@imsa.edu>
Message-Id: <91Jun21.103256pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 21 Jun 1991 10:32:42 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: ken@imsa.edu
Cc: moo-cows@arisia.Xerox.COM
Subject: Re: logout actions, or rather, lack thereof

Kenneth C. Schalk writes:
>     2) Get some wizard to own my @quit, so that I can put a
> boot_player(player); in it.

As of release 1.3 of the server, you no longer need wizard permissions to boot
yourself.

	Pavel/Haakon

From pavel@arisia.Xerox.COM Fri Jun 21 11:25:17 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19759; Fri, 21 Jun 91 11:25:12 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA16304; Fri, 21 Jun 91 11:18:39 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11673>; Fri, 21 Jun 1991 11:18:35 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 21 Jun 1991 11:18:16 -0700
In-Reply-To: <9106210802.AA00572@imsa.edu>
Message-Id: <91Jun21.111816pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 21 Jun 1991 11:18:16 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re:  logout actions, or rather, lack thereof

Kenneth C. Schalk writes:
>     I may have to (unfortunately, and unwillingly) rescind my earlier
> suggestion.  I ahve been talking with Grump for some time now about
> whether or not this could possibly open up any security holes.  For
> the most part, we found none.  However, under certain circumstances,
> if one changes the value of the 'this' variable, the !x passing could
> be misused.
> 
>     For example, if I were to create a child of some other player, and
> add a @mail verb to it, in which I did something like:
> 
> this=parent(this);
> pass();
> 
> I could potentially read that persons mail.

This contains at least one misconception: the working of the `pass()' function
is not based upon the current value of `this' or, indeed, on any value of that
variable at all.  It is, rather, based upon the identity of the object on which
the currently-running verb is defined.  Thus, no amount of changing `this' will
have any effect on `pass()'.

	Pavel/Haakon

From pavel@arisia.Xerox.COM Fri Jun 21 11:27:03 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19766; Fri, 21 Jun 91 11:26:59 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA16361; Fri, 21 Jun 91 11:21:13 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11658>; Fri, 21 Jun 1991 11:21:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11658>; Fri, 21 Jun 1991 11:20:39 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 21 Jun 1991 11:20:32 -0700
X-Ns-Transport-Id: 08002008D0FD000CBFFC
In-Reply-To: <9106211442.AA01723@tempest>
Message-Id: <91Jun21.112032pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 21 Jun 1991 11:20:21 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: asun@ocf.berkeley.edu
Cc: moo-cows.PARC@xerox.com
Subject: Re: just a reminder

a sun writes:
> MOO-Cows is a mailing list for primarily server issues. questions
> dealing with the LambdaDB will often receive more feedback if the
> internal LambdaMOO mailing lists are used, help is consulted, or
> wizards/other LambdaMOO programmers are asked. in particular,
> *Core-DB-Issues might be of interest for those seeking modification of
> the DB on Lambda.

Actually, MOO-Cows is for discussion of any MOO-programming-related topic,
including core database issues.  In this it somewhat overlaps the purpose of
the *Core-DB-Issues mailing list on LambdaMOO, but that's OK with me.

	Pavel/Haakon

From ken@imsa.edu Fri Jun 21 11:47:00 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA19857; Fri, 21 Jun 91 11:46:57 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <11678>; Fri, 21 Jun 1991 11:41:40 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA02633; Fri, 21 Jun 91 13:41:35 CDT
Message-Id: <9106211841.AA02633@imsa.edu>
Date: 	Fri, 21 Jun 1991 11:41:35 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: moo-cows@arisia.xerox.com, pavel@parc.xerox.com
Subject: Re:  logout actions, or rather, lack thereof

Pavel Curtis writes:
>This contains at least one misconception: the working of the `pass()'
>function is not based upon the current value of `this' or, indeed, on
>any value of that variable at all.  It is, rather, based upon the
>identity of the object on which the currently-running verb is defined.
>Thus, no amount of changing `this' will have any effect on `pass()'.

    No, actually, I understood that.  The problem is that the @mail
[related] verbs send all their text through player:tell, yet read the
mail from this.<mail-properties>.  Assuming that one could use pass()
on !x verbs, you could set `this' to whoever you please, and
potentially read their mail.
    After this and some other thought, I'd like to further clarify
what I was suggesting (even though a sun <asun@ocf.berkeley.edu>
already pointed out that disfunc is available.  (Sorry, I guess I
ought to ftp that new programmer's manual :-)

    Anyway, I think that pass()ing to a !x verb could be safe if the
following conditions are met:

    1) Both the calling and receiving verb are !x.
    2) Both verbs have the same dobj, prep, and iobj specifiers.
    3) None of the predefined variables (this, dobj, iobj, etc.) get
cahnged before the pass().  (Or, alternatively, they get reset when
pass()ing.)

    That last one, although probably difficult to implement, seems to
me to plug up the few potential security holes that could be cause by
allowing !x pass()ing.

    Ken/Xorian[s]


From pavel@arisia.Xerox.COM Fri Jun 21 11:59:37 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19906; Fri, 21 Jun 91 11:59:35 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA16931; Fri, 21 Jun 91 11:53:31 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11658>; Fri, 21 Jun 1991 11:53:29 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 21 Jun 1991 11:53:19 -0700
In-Reply-To: <9106211557.AA14801@att1.Mankato.MSUS.EDU>
Message-Id: <91Jun21.115319pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 21 Jun 1991 11:53:06 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: logout actions, or rather, lack thereof

Jay A. Carlson writes:
> > i've never thought that the use of verbs was a
> > kludge. in fact, i prefer manipulation of characteristics through
> > verbs rather than modification of properties (i.e., :description() and
> > :title()).
> 
> I agree with you.  But for security reasons, often verbs must be
> kludged to depend on secure properties.  If verbs had something like
> the 'c' bit to stop overriding, a lot of secured objects would become
> much simpler.
> 
> LambdaMOO would act more OO if verbs could be secured as well as
> properties, IMHO.

I agree and have several times given some thought as to the right way to
support verb permissions, including perhaps the ability to prevent overriding.

One problem is the somewhat messy way in which `pass()' is defined to work:
control is passed to the verb you find by starting on the parent of the current
verb's location and searching for a verb using *the same name as was used to
find the current verb*.  In the presence of multiple names for verbs, this
implies that you have to be *very* careful to use precisely the same set of
names for your verb as your parent did.  Of course, if the parent's verb names
are changed for any reason, robustness requires that one carefully examine the
verb lists of all descendants to make sure that they are consistently updated.

I have an idea intended to fix this much of the problem; what follows doesn't
directly address what Jay is asking for, but rather this problem in cleanly
specifying the issue.

Remove the functions verb_args() and set_verb_args(); also, change verb_info()
and set_verb_info() to traffic in two-element lists, just like property_info()
and set_property_info().  Add two new functions, verb_syntax() and
set_verb_syntax(), similar to [set_]verb_args(), that traffic in lists with the
following form:
	{names, dobj, prep, iobj}
where `names' is a list of strings giving names for the verb (rather than the
current space-separated string, which always struck me as a crock), and `dobj',
`prep', and `iobj' are as in [set_]verb_args() today.

The upshot of the change is that every verb will have a single, simple name,
just like properties (e.g., no embedded stars for abbreviation).  This is the
only name by which programs can invoke the verb and the only name used in
figuring out what `pass()' should do.  Additionally, a given verb *may* have a
syntax by which it can be invoked from the command line.  The `names' that are
a part of the syntax of a verb are completely separate and unrelated to the
actual, programming-language name for the verb.  In essence, the syntax is the
user interface while the true name is the programming interface.  [Various
conventions, supported by the various verb-creation commands, might be
contrived to make it as easy as possible to guess the verb name based upon the
names in its syntax.]

There should be two special values of verb syntax:

-- Something meaning `this verb has *no* syntax; it cannot be invoked from the
   command line'.  We *could* continue to use the `this none this' crock, but
   it would be better to have a special value for the purpose.
-- Something meaning `this verb inherits its syntax from the verb with the
   same name on its parent (or nearest ancestor defining such a verb)'.  I
   refer to this special value as being `clear' or `transparent', since the
   parent's syntax `shows through' into the child.  This would allow child
   objects to override or specialize the *behavior* of a parent's verb without
   having to duplicate its *interface*.

[Tangentially, I intend to implement this notion of `transparency' for property
values soon, so that a child would initially have `clear' values for all
inherited properties; this would avoid copying the values in the parent and
also allow children who are using the default value to track changes in the
parent.  There will be functions for testing whether or not a given property is
`clear' and for making it so; simple assignment will suffice to give a property
its own value, cancelling the `transparency'.]

Comments?

	Pavel/Haakon

From pavel@arisia.Xerox.COM Fri Jun 21 12:14:53 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19996; Fri, 21 Jun 91 12:14:52 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA17260; Fri, 21 Jun 91 12:07:56 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11781>; Fri, 21 Jun 1991 12:07:48 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 21 Jun 1991 12:07:35 -0700
In-Reply-To: <9106211841.AA02633@imsa.edu>
Message-Id: <91Jun21.120735pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 21 Jun 1991 12:07:34 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re:  logout actions, or rather, lack thereof

Kenneth C. Schalk writes:
> The problem is that the @mail
> [related] verbs send all their text through player:tell, yet read the
> mail from this.<mail-properties>.  Assuming that one could use pass()
> on !x verbs, you could set `this' to whoever you please, and
> potentially read their mail.

Again, a misconception.  The value of `this' in the calling verb is not related
to the value of `this' in the called verb.  The following variables have their
values inherited by the called verb (whether by pass() or normal verb call):

	dobj	dobjstr   prepstr
	iobj	iobjstr	  argstr
	player (but only if the calling verb is running with wizard perms)

Even this is not entirely correct, but it is close to the truth; the true
details are too gross to mention.

There exists a version of the manual that describes this, but I'm not sure that
it's the released version.  I should really get around to putting out the
latest version on belch...

	Pavel/Haakon

[One of the things I would dearly like to get fixed in the language is argument
passing; this kind of `variable inheritance' is gross, as is the fact that
verbs do not take named arguments like in real languages and must check for
number-of-arguments errors manually.  This is all bound up with the details of
the parser, unfortunately, and I haven't had time to really work on a complete
redesign of that yet, though Aladdin and I have the outlines of a much better
system.]

From joe@dot Fri Jun 21 13:48:01 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <joe@dot>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA20382; Fri, 21 Jun 91 13:47:57 PDT
Received: from RUTGERS.EDU by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA18749; Fri, 21 Jun 91 13:41:32 -0700
Received: from unipress-link.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA08890; Fri, 21 Jun 91 16:41:06 EDT
Received: from dot.unipress by repo.unipress.com.unipress (4.1/SMI-4.1)
	id AA05021; Fri, 21 Jun 91 16:37:06 EDT
Received: by dot.unipress (4.1/SMI-4.1)
	id AA15543; Fri, 21 Jun 91 16:38:08 EDT
Message-Id: <9106212038.AA15543@dot.unipress>
Date: Fri, 21 Jun 91 16:38:08 EDT
From: joe@dot (Technomystic at large.)
To: moo-cows@arisia.Xerox.COM
Subject: Verb permissions, etc. (was: Re: logout action, or rather, lack thereof)

Pavel Curtis <pavel@parc.xerox.com>:
> every verb will have a single, simple name, just like properties (e.g., no
> embedded stars for abbreviation).  This is the only name by which programs
> can invoke the verb and the only name used in figuring out what `pass()'
> should do.  Additionally, a given verb *may* have a syntax by which it can
> be invoked from the command line.  The `names' that are a part of the
> syntax of a verb are completely separate and unrelated to the actual,
> programming-language name for the verb.  In essence, the syntax is the
> user interface while the true name is the programming interface.

Yes!  Please!  Separate the user interface from the programmer interface.
Segregate command syntax from program syntax as much as possible.  There
won't be any asprin left for the rest of us if you address the issues
concerning a command language and a programming language at the same time.
Especially with the strange namespace shapes attainable in Object Oriented
languages.  Don't believe me?  Take a look at the arcane and bizzare ways
in which Emacs is made to read command arguments from the user.

> Something meaning `this verb has *no* syntax; it cannot be invoked from
> the command line'.  We *could* continue to use the `this none this' crock,
> but it would be better to have a special value for the purpose.

There is no such thing as a good crock.  This particular one is especially
offensive to me for some reason.

--joe (AKA: Khalarhgast) joe@dot.unipress.com



From latour!mcr Fri Jun 21 18:06:17 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA21174; Fri, 21 Jun 91 18:06:13 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA02482; Fri, 21 Jun 91 18:00:18 -0700
Received: from bertrand.ccs.carleton.ca ([134.117.1.13]) by alpha.xerox.com with SMTP id <11865>; Fri, 21 Jun 1991 18:00:09 PDT
Received: from latour.UUCP by bertrand.ccs.carleton.ca (4.1/SMI-4.0)
	id AA24450; Fri, 21 Jun 91 20:58:59 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA08681; Fri, 21 Jun 91 18:54:59 EDT
Message-Id: <9106212254.AA08681@Sandelman.OCUnix.On.Ca>
In-Reply-To: Pavel Curtis <pavel@parc.xerox.com>
       "Re: logout actions, or rather, lack thereof" (Jun 21, 11:53am)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Date: 	Fri, 21 Jun 1991 15:54:57 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
To: MOO COWS <moo-cows@arisia.Xerox.COM>
Subject: Re: logout actions, or rather, lack thereof

On Jun 21, 11:53am, Pavel Curtis wrote:
} [Tangentially, I intend to implement this notion of `transparency' for property
} values soon, so that a child would initially have `clear' values for all
} inherited properties; this would avoid copying the values in the parent and
} also allow children who are using the default value to track changes in the
} parent.  There will be functions for testing whether or not a given property is
} `clear' and for making it so; simple assignment will suffice to give a property
} its own value, cancelling the `transparency'.]

  Oh yes, please!!!
  I was looking through property.c, pondering how to do this. I had
a couple of thoughts:
  (1) make a special value `clear', and wander up the hierachy looking for
the property if you get that value.
  (2) rework the way properties are organized, so that a property isn't
actually ADDED to a child until it gets a value -- all access recurses
upwards. (could be costly) 

  I like (2) for one reason though --- it would let me redefine a
property on a child. I have had reasons to do this before, but it has
been a couple months since I've done any MOOing, so I can't recall
them right now. Of course, I do some wierd things with MOO.

  Concerning :title() vs .name --- couldn't we do away completely with
the distinction between verbs and properties? That would be much nicer
in my opinion. I know this would be a major thing to do, but it makes
overriding things (there is already a bunch of stuff to deal with
.description) a lot easier, and more robust.

  this:title() = "Joe"

  would be one possible syntax for assignment. This _could_ call a
second verb if this was in fact a verb, or could simply be an error.


-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!



From nop@att1.mankato.msus.edu Fri Jun 21 18:24:59 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <nop@att1.mankato.msus.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21195; Fri, 21 Jun 91 18:24:56 PDT
Received: from att1.Mankato.MSUS.EDU ([134.29.254.1]) by alpha.xerox.com with SMTP id <11865>; Fri, 21 Jun 1991 18:20:26 PDT
Received:  by att1.Mankato.MSUS.EDU (5.59/25-eef)
	id AA16583; Fri, 21 Jun 91 20:20:03 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
Message-Id: <9106220120.AA16583@att1.Mankato.MSUS.EDU>
In-Reply-To: Pavel Curtis's message of Fri, 21 Jun 1991 11:53:06 PDT <91Jun21.115319pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 21 Jun 1991 18:20:03 PDT
From: <nop@att1.mankato.msus.edu>
To: pavel@parc.xerox.com
Cc: moo-cows@arisia.xerox.com
Subject: logout actions, or rather, lack thereof

> [Tangentially, I intend to implement this notion of `transparency'
> for property values soon, so that a child would initially have
> `clear' values for all inherited properties; this would avoid
> copying the values in the parent and also allow children who are
> using the default value to track changes in the parent.  There will
> be functions for testing whether or not a given property is `clear'
> and for making it so; simple assignment will suffice to give a
> property its own value, cancelling the `transparency'.]

This will also make object browsing (and my object browser in
particular) much more user-friendly.  Right now, browser users suffer
from a weight of usually-useless information.  A good deal of my time
is being spent on selective-display heurustics.

 ---Jonny

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

To subscribe to the MC68HC11 list, email to mc68hc11-request@quack.sac.ca.us.

From crew@neon.stanford.edu Sat Jul  6 20:00:14 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA22021; Sat, 6 Jul 91 20:00:11 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA16567; Sat, 6 Jul 91 19:49:00 -0700
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11701>; Sat, 6 Jul 1991 19:48:54 PDT
Received: from Boole.Stanford.EDU by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA18323; Sat, 6 Jul 91 19:48:48 -0700
Message-Id: <9107070248.AA18323@Neon.Stanford.EDU>
Date: 	Sat, 6 Jul 1991 20:44:01 PDT
From: Roger Crew <crew@cs.stanford.edu>
To: moo-cows@arisia.Xerox.COM
Subject: grumbles about index()/rindex()

;index("","")
=>  0
;rindex("","")
=>  0

IMHO, these are wrong.

My understanding of index(string,target), and this is implied by the description in the prog.manual, is that it returns nonzero whenever 'target' is a substring of 'string', and the empty string should, by rights, be regarded as a substring of anything.  Likewise for rindex().

Granted, the question of what the position of the first character of an occurence of "" might be is somewhat problematical, but for continuity's sake, I'd suggest having the following always hold:

 index(string,string)==1
rindex(string,string)==1

 index(string,"")==1
rindex(string,"")==length(string)+1

.

From pavel@arisia.Xerox.COM Thu Jul 18 17:45:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA23444; Thu, 18 Jul 91 17:45:27 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01019; Thu, 18 Jul 91 17:19:57 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11910>; Thu, 18 Jul 1991 17:19:55 PDT
Received: by lambda.parc.xerox.com id <58369>; Thu, 18 Jul 1991 17:19:27 -0700
Message-Id: <91Jul18.171927pdt.58369@lambda.parc.xerox.com>
Date: 	Thu, 18 Jul 1991 17:19:25 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: forwarded message from jsmart@iastate.edu

John, submissions to the MOO-Cows mailing list should be sent to
	MOO-Cows@Xerox.Com
not
	MOO-Cows-Request@Xerox.Com

The latter address is only for list-administration messages (e.g., `please add
me', `please delete me', etc.).

	Pavel/Haakon/Lambda

------- Start of forwarded message -------
Date: 	Thu, 18 Jul 1991 16:23:53 PDT
From: jsmart@iastate.edu
To: MOO-Cows-Request.PARC@xerox.com
Subject: Event driven reactions.

I'm trying to build a two-way radio.

How do I catch and transmit what the holder of the radio says without
changing the holder's "say" verb?  In other words, for the algorithim(sp?)

if (transimitter_is_on && holder_says_something) then....

What would be the code of holder_says_something?

I know I could simply define a "transmit (text)" verb on the the radio itself,
but there are other examples where a device activated by someone saying
something would be nice.  (Trying to make conversation able MOO-Eliza[1], for
example.)

Any suggestions?

						-John
						Cassnak on LambdaMOO

[1] Eliza is a program that takes your response and scans it for keyphrases
and keywords to come up with an intelligent sounding response.  The key phrase
"You are *" will often prompt Eliza to come back with "Would you like me to be
*" or "What makes you think I am *" or something similar.  The program is
easy.  It's building a convincing response database that is the challenge.
------- End of forwarded message -------

From asun@ocf.berkeley.edu Mon Jul 22 07:52:05 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <asun@ocf.berkeley.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA28627; Mon, 22 Jul 91 07:52:02 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA16792; Mon, 22 Jul 91 07:40:19 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11522>; Mon, 22 Jul 1991 07:40:16 PDT
Received: from monsoon.Berkeley.EDU ([128.32.234.13]) by alpha.xerox.com with SMTP id <11522>; Mon, 22 Jul 1991 07:39:28 PDT
Received: by monsoon.Berkeley.EDU (5.61/CHAOS)
	id AA04572; Mon, 22 Jul 91 07:30:18 -0700
X-In-Real-Reply-To: forwarded message from jsmart@iastate.edu
X-Ns-Transport-Id: 08002008D0FD000E0554
In-Reply-To: "asun's message of Mon, 22 Jul 91 07:02:57 EST"
Message-Id: <9107221430.AA04572@monsoon.Berkeley.EDU>
Date: 	Mon, 22 Jul 1991 07:30:18 PDT
From: a sun <asun@ocf.berkeley.edu>
To: moo-cows.PARC@xerox.com
Subject: Event driven reactions.


sigh. arisia.xerox.com doesn't seem to have a sendmail daemon running.
is it supposed to have one, or did someone forget to MX it?

[once again]

   I'm trying to build a two-way radio.

   How do I catch and transmit what the holder of the radio says without
   changing the holder's "say" verb?  In other words, for the algorithim(sp?)

the standard method of making actions depend on readable activity is
through the use of a modified :tell() verb. since the :tell() verb
captures all displayed activity, it is fairly simple to have certain
actions become triggers. in your case though, i believe that ford has
already created a two-way radio.i'm not sure what the object number
is, but you can see an instance of it in the living room. it is aptly
named the 'potted plant.'
 
   but there are other examples where a device activated by someone
   saying something would be nice.  (Trying to make conversation able
   MOO-Eliza[1], for example.)

grump has created a fairly good example of an eliza/julia-type robot
in his 'generic friend.' it is quite sophisticated although it does
fall prey to robot detectability and annoyance.

-a



From @unhtel.uucp:forrie@morwyn.uucp Tue Jul 23 20:33:13 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@unhtel.uucp:forrie@morwyn.uucp>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03978; Tue, 23 Jul 91 20:33:11 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA02876; Tue, 23 Jul 91 20:22:17 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11693>; Tue, 23 Jul 1991 20:22:07 PDT
Received: from unhd.unh.edu ([132.177.128.6]) by alpha.xerox.com with SMTP id <11714>; Tue, 23 Jul 1991 20:21:34 PDT
Received: by unhd.unh.edu (5.57/Ultrix3.0-C.tjb)
	id AA11000; Tue, 23 Jul 91 23:21:11 -0400
Received: by unhtel.unh.edu (smail2.5)
	id AA02591; 23 Jul 91 23:16:14 EDT (Tue)
Received: by morwyn.UUCP (/\==/\ Smail3.1.21.1 #21.1)
X-Location: Dover, NH  03820
X-Mailer: ELM [version 2.4dev PL43]
X-Ns-Transport-Id: 08002008D0FD000E1E68
Message-Id: <m0k2Zj3-0000SAC@morwyn.UUCP>
Date: 	Tue, 23 Jul 1991 20:17:21 PDT
From: morwyn!forrie (Forrie Aldrich)
Sender: unhtel!forrie%morwyn.uucp
To: MOO-Cows.PARC@xerox.com
Subject: Porting and compiling LambdaMOO and non-networking systems
Reply-To: uunet!root%morwyn.uucp%unhtel.uucp%virgin.uucp

Hello fellow Mooers:

I'm interested in getting LambdaMOO to compile on a non-networked system,
particularly that of System V Unix.  And from conversations I have had,
Haakon is interested in this as well.

I would like to know if there are others out there who might have similar
interests or if anyone out there might be working on such a port. 

According to Haakon, LambdaMOO was written so that the networking code in
bsd_network.c could be hacked to enable a single user mud (non-networking).
Whereas it would not allow multiple users.

TinyMUD2 has some patches (available in comp.sources.games/volume11) that
you apply to its code that alters the program to use IPC Message Queues
(System V's version of sockets I guess) and FIFOs.  It works fine and
allow multiple users on a non-networking machine.

Unfortunately, my C programming experience is way out of wack... too much
to be able to create a port of this sort or dimension.  So I ask:  Would
someone out there volunteer to help out?

LambdaMOO is, by far, a very powerful interface.  It should be implemented
further on the net.  I feel that allowing LambdaMOO to spread to non-
networking machines will help considerably in promoting it, as well as
allowing users to have their own MOO environ with which to work and build
and porting their buildings to a larger MOO later.

Okay, enough said :)  I'd appreciate hearing any and all opinions of this,
as well as any help! 

Thanks,

Forrie
(aka Akiim)

PS:  Please send to:  uunet!virgin!unhtel!morwyn!root or forrie
--------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--------------------
Forrest Aldrich, Jr.|   (a reliable path here someday)   |forrie@morwyn.UUCP
                    |           <email paths>            | 
CREATIVE CONNECTIONS|  uunet!virgin!unhtel!morwyn!forrie |Graphic Illustration
------------------\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/------------------
                   \___ PO Box 1541 - Dover, NH  03820 ___/                   

From ramsey@arisia.Xerox.COM Mon Jul 29 12:22:50 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ramsey@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA14885; Mon, 29 Jul 91 12:22:48 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA21098; Mon, 29 Jul 91 12:11:58 -0700
Received: from worsel.parc.xerox.com ([13.2.116.58]) by alpha.xerox.com with SMTP id <11563>; Mon, 29 Jul 1991 12:11:50 PDT
Received: by worsel.parc.xerox.com id <34>; Mon, 29 Jul 1991 12:11:28 -0700
Message-Id: <91Jul29.121128pdt.34@worsel.parc.xerox.com>
Date: 	Mon, 29 Jul 1991 12:11:14 PDT
From: Norman Ramsey <ramsey@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Impressions of a new MOOer

I spent part of the weekend poking around the LambdaMOO with my
programming manual and my brand-new programmer's bit.  Here are my
impressions: 

The essential MOO-ness of the MOO is not found in the MOO programming
language, but is divided between the builtin procedures of the
language and the objects and procedures found in the core database.
New users need know nothing of the language, but they need to know the
rich set of commands provided in the core (commands that `help' tells
about), *then* they need to learn about the rich set of generic
objects and the verbs they understand.  I find the resulting Gestalt
very complex.

New programmers have a similar task ahead: they need to master the
`utilities' built in to the core database.  It also helps them to have
some idea what's been done: creativity is stifled when a new
programmer works hard on a teleporter, only to discover that players
already have three others that they like better.

The MOO language is simple, but wizards and users have built a very
complex system (the core database) on this simple substrate.  I claim
that, to be truly accessible to new users and programmers, this
complexity has to be organized and documented.  For example:

     -- the MOO could be instrumented to discover which commands are
	used most often and which help is asked for most often.  This
	information could be used to prepare a ``kindergartener's
	guide'' to the moo, which could ignore most things.

     -- The core database could be periodically redesigned and
	reorganized, taking into account the lessons learned from the
	current version.  Some instrumentation about verb usage could
	be helpful here.  This plan needs a strong wizard who is able
	to say no to interesting things in order to keep things
	simple.  Perhaps this is not a good way to build a MOO, but I
	think that is an interesting experimental question.

I was disappointed in the programming language reference manual; such
a simple language should be able to have a 50-page manual.  I think
part of the problem is that the manual attempts to be both reference
and tutorial.  I hope that organizing the same information differently
would yield a pair of documents, reference and tutorial, that would be
more useful without increasing the page count.  Interesting verbs in
the core database are proper fodder for tutorial things; the contrived
examples full of foo and baz are annoying.

Here's a concrete goal: one document, no more than 50 pages, that is a
complete guide to orient the new player.  Its purpose would be to
orient the player in the MOO environment, not to be comprehensive.
A second, similar document, for new programmers.  Comprehensive
reference materials are nice, but I think tutorials should have
priority, especially in cases where the information is available on
line.  (That's quite a concession from a lover of printed
documentation.)  I would be willing to help edit such documents.

In closing, I think the builders and programmers of the Lambda House
have done a wonderful job making it a fascinating (if bewildering)
place.  My hat is off to them.  I've done all this griping because I
want to play too, but I can't afford the time off from research for
the total immersion method.

Norman Ramsey
nr@princeton.edu

From jashley@arisia.Xerox.COM Mon Jul 29 13:19:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <jashley@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA15061; Mon, 29 Jul 91 13:19:54 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA22177; Mon, 29 Jul 91 13:08:48 -0700
Received: from miles.parc.xerox.com ([13.2.17.18]) by alpha.xerox.com with SMTP id <11542>; Mon, 29 Jul 1991 13:08:43 PDT
Received: by miles.parc.xerox.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA04598; Mon, 29 Jul 91 13:06:52 PDT
Message-Id: <9107292006.AA04598@miles.parc.xerox.com>
In-Reply-To: Norman Ramsey's message of Mon, 29 Jul 1991 12:11:14 -0700 <91Jul29.121128pdt.34@worsel.parc.xerox.com>
Date: 	Mon, 29 Jul 1991 13:06:52 PDT
From: jashley@parc.xerox.com
To: moo-cows@arisia.Xerox.COM
Subject: Impressions of a new MOOer


   The MOO language is simple, but wizards and users have built a very
   complex system (the core database) on this simple substrate.  I claim
   that, to be truly accessible to new users and programmers, this
   complexity has to be organized and documented.

I'm not so sure I agree with this.  One organizes and documents a static
system.  The MOO is not static; it is always evolving.  And with the
exception of the core database, the MOO is not even monotone.  You
can only organize and document a snapshot, and that's not I want to
see in the long run.  Furthermore, just documenting the code database
isn't enough.  (I bet) there are lots of fine MOO objects that aren't 
in the core database and would be useful to many people.  What one person
can document it all?

I don't have a good solution to the problem, however.  Some kind of 
object browser might be a start for at least getting an idea of what 
exists in the world and how it is all related.  @classes generics 
tells me about a few generics, but it just doesn't do it for me.  I'm
not ready to articulate why, though.

How verbs are documented is much more difficult.  I don't believe that
MOO code can be separately documented, which leads to a gripe of mine.
I'm critical of the decision to throw away comments when code is parsed.
I don't understand this decision when so many different people have to 
read each other's code on a daily basis.  Sure, *some* people can read 
the code as is, probably most of the people on this list, but that's not 
the point.  *All* people should be able to read and understand the code.

So just to repeat myself, static organization and documentation is not
worthwhile in the long run.  We need to look for ways of having the
world be self-documenting.

   I was disappointed in the programming language reference manual; such
   a simple language should be able to have a 50-page manual.  I think
   part of the problem is that the manual attempts to be both reference
   and tutorial.

Sorry, I didn't get the impression that it was a tutorial at all.

The actual programming language reference looks to be 40 pages.  The rest
of the manual describes related things like the database and parsing, which
are relevant to anyone who's going to program.  I'm not so sure that Chapter
4, Server Commands and Database Assumptions needs to be in the programmer's
manual.

   I hope that organizing the same information differently
   would yield a pair of documents, reference and tutorial, that would be
   more useful without increasing the page count.  Interesting verbs in
   the core database are proper fodder for tutorial things; the contrived
   examples full of foo and baz are annoying.

A tutorial *is* needed, with good examples.  Everybody knows this and nobody
has the time to write it.  It's a real bummer.

   Here's a concrete goal: one document, no more than 50 pages, that is a
   complete guide to orient the new player.  Its purpose would be to
   orient the player in the MOO environment, not to be comprehensive.

I'd like to see an outline of such a document.  What's need to orient a
new player besides the obvious "don't be rude"?  The way people behave
and interact in the MOO goes way beyond a treatise on deviance in the
MOO.  I certainly don't have a handle on it.

   [...] I want to play too, but I can't afford the time off from 
   research for the total immersion method.

Yeah, so what's your point?  :-)


From ramsey@arisia.Xerox.COM Mon Jul 29 13:42:43 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ramsey@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA15157; Mon, 29 Jul 91 13:42:41 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA22719; Mon, 29 Jul 91 13:34:46 -0700
Received: from worsel.parc.xerox.com ([13.2.116.58]) by alpha.xerox.com with SMTP id <11580>; Mon, 29 Jul 1991 13:34:37 PDT
Received: by worsel.parc.xerox.com id <34>; Mon, 29 Jul 1991 13:33:49 -0700
Message-Id: <91Jul29.133349pdt.34@worsel.parc.xerox.com>
Date: 	Mon, 29 Jul 1991 13:33:42 PDT
From: Norman Ramsey <ramsey@parc.xerox.com>
To: jashley@parc.xerox.com, moo-cows@arisia.Xerox.COM
Subject: Re:  Impressions of a new MOOer

> One organizes and documents a static
> system.  The MOO is not static; it is always evolving.  

And therefore should be disorganized and undocumented?  I don't buy
it. 

> You can only organize and document a snapshot, and that's not I want to
> see in the long run. Furthermore, just documenting the code database
> isn't enough.  (I bet) there are lots of fine MOO objects that aren't 
> in the core database and would be useful to many people.  What one person
> can document it all?

You seem to be arguing in favor of documenting nothing.  Time spent
documenting is time that can't be spent hacking or building or doing
other fun things.  But I want a New Jersey approach: better documents
of a snapshot now.  Perfection in the long run is goal I'm less
interested in.

> We need to look for ways of having the world be self-documenting.

This strikes me as an interesting and difficult research problem.  It
does not strike me as a way to get a better-documented or more easily
usable MOO.

> I'd like to see an outline of such a document.  What's need to orient a
> new player besides the obvious "don't be rude"?  

I don't have an outline, but here's some information I'd like to see:

  Value judgements about commands:
    `look' is more interesting than `@show'
    `n' is more interesting than `@move'
  description that ignores building until I'm ready for it.  Ditto programming.
  
Here's another interesting exercise: suppose you had to limit yourself
to a command set that could be documented on one page?  What would you
include? Now add a second page for building.  A third for programming.

> Yeah, so what's your point?  :-)

My point is that the MOO is very complex, and the complexity is poorly
organized, so that it is not possible to consume information
selectively.  This makes it very attractive for a certain personality
(those who enjoy Unix or Flavors come to mind).  I thought one point
of the MOO was to reach a different kind of personality.


Norman Ramsey
nr@princeton.edu

From jashley@arisia.Xerox.COM Mon Jul 29 14:19:23 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <jashley@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA15239; Mon, 29 Jul 91 14:19:21 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA23350; Mon, 29 Jul 91 14:09:15 -0700
Received: from miles.parc.xerox.com ([13.2.17.18]) by alpha.xerox.com with SMTP id <11576>; Mon, 29 Jul 1991 14:09:06 PDT
Received: by miles.parc.xerox.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA04619; Mon, 29 Jul 91 14:07:10 PDT
Message-Id: <9107292107.AA04619@miles.parc.xerox.com>
In-Reply-To: Norman Ramsey's message of Mon, 29 Jul 1991 13:33:42 -0700 <91Jul29.133349pdt.34@worsel.parc.xerox.com>
Date: 	Mon, 29 Jul 1991 14:07:10 PDT
From: jashley@parc.xerox.com
To: moo-cows@arisia.Xerox.COM
Subject:  Impressions of a new MOOer


   You seem to be arguing in favor of documenting nothing.  Time spent
   documenting is time that can't be spent hacking or building or doing
   other fun things.

Let me use this comment to abstract a little bit.  Documentation and
organization is an investment.  It gains you nothing or very little
at the time you do it, but it will start to pay off when other people
have to use the system or want to borrow code from the system in the 
future.  This investment is probably worth it if the system is static.

But again, the MOO is not static.  Let's say someone sits down and spends
a week writing documentation.  I think it would take longer to do it
right, but let's say this person is dynamite.  Three months later, that
documentation is going to be needing some revision.  It'll be
inaccurate (e.g. objects it describes have been recycled) or else 
insufficient (e.g. objects it doesn't describe have been created).
Far worse, some objects it describes may have been changed in subtle
ways.  To be sure, the author will have to go through the entire
manual and database and verify that the documentation reflects the
state of the world.  Not pleasant, after just a few short months.
The investment was probably not worthwhile.

This ends up as being a criticism of my own point of view that people
need to comment their code.  Once again, the same principle applies:
it's not worth commenting code that is likely to change in the near
future.  Code that does hang around (e.g. verbs that are attached to 
generics) do get documented, however.  An example of such documentation 
is Frand's big manual in the library.

I'm not in favor of documenting nothing.  Just the opposite.  But
I also think that static documentation of the MOO is hopeless in
terms of the amount of resources it would require to keep it (somwhat)
accurate.

   But I want a New Jersey approach: better documents
   of a snapshot now.  Perfection in the long run is goal I'm less
   interested in.

:shrugs, "I guess this is where we differ."

   > Yeah, so what's your point?  :-)

   My point is ...

Hey, I was making a joke about your priorities!  

Cheers.

From @vaxb.acs.unt.edu:cluther@morticia.cnns.unt.edu Mon Jul 29 14:32:47 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@vaxb.acs.unt.edu:cluther@morticia.cnns.unt.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA15297; Mon, 29 Jul 91 14:32:44 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA23856; Mon, 29 Jul 91 14:26:26 -0700
Received: from Minos.Parc.xerox.xns by alpha.xerox.com via XNS id <11572>; Mon, 29 Jul 1991 14:26:12 PDT
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11559>; Mon, 29 Jul 1991 13:50:19 PDT
Received: by sonne (4.1/1.36)
	id AA18013; Mon, 29 Jul 91 15:43:44 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD000E787A
Message-Id: <9107292043.AA18013@sonne>
Date: 	Mon, 29 Jul 1991 13:43:40 PDT
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@arisia.Xerox.COM (Moo Cows)
Subject: Impressions of a new MOOer (reply)

> The MOO language is simple, but wizards and users have built a very
> complex system (the core database) on this simple substrate.  I claim
> that, to be truly accessible to new users and programmers, this
> complexity has to be organized and documented.  For example:

> more useful without increasing the page count.  Interesting verbs in
> the core database are proper fodder for tutorial things; the contrived
> examples full of foo and baz are annoying.

> In closing, I think the builders and programmers of the Lambda House
> have done a wonderful job making it a fascinating (if bewildering)
> place.  My hat is off to them.  I've done all this griping because I
> want to play too, but I can't afford the time off from research for
> the total immersion method.
> 
> Norman Ramsey
> nr@princeton.edu

I must agree with Norman on all accounts.  Moo is quite fascintating, though
the LambdaCore has such a "black box" feel to it that it is quite indomitable.
Although Moo *looks* like the mud-to-replace-all-muds, it currently suffers
from two radically different ends of the same problem: NO REASONABLE CORE.

On one hand, the minimal.db (and minimal.help that comes with it) is of very
little help.  Sure, you can make an primitive eval(), but it is very difficult
to move on from there.  The lack of support given to the people brave or dumb
enough to spend time working up a core completely from scratch is
disheartening.

On the other hand, there is the huge LambdaCore with all of its bells and
whistles.   I printed out all of the verbs and objects from this beast and
ended up with *TWO LARGE* three ring document binders full of stuff.  I
estimate over 600 pages worth of material.  Here, the task is not so much of
building as discovering, which, hampered by any reasonable documentation on the
Core, makes this a very hard task as well.

Moo needs *another* core to become popular and successful with friendly system
managers like myself who are *QUITE* willing to sacrifice CPU and storage to a
Moo but don't have the time to either code one up from scratch or decipher the
black box LambdaCore.  This core would contain some simple definitions of
common verbs and objects, and maybe a few rooms.  And, of course, reasonable
documentation.

Such a beast would handily make setting up a Moo easier.

BTW, If anyone has one of these things, send it to me.  I *will* use it.

That is all.

-- 
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               ** Omegans, Just a GB Manager **

From pavel@arisia.Xerox.COM Mon Jul 29 16:04:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA15567; Mon, 29 Jul 91 16:04:38 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA25022; Mon, 29 Jul 91 15:28:33 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11592>; Mon, 29 Jul 1991 15:28:29 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 29 Jul 1991 15:28:05 -0700
In-Reply-To: <9107292043.AA18013@sonne>
Message-Id: <91Jul29.152805pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 29 Jul 1991 15:27:49 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Impressions of a new MOOer (reply)

Clay Luther writes:
> On one hand, the minimal.db (and minimal.help that comes with it) is of very
> little help.  Sure, you can make an primitive eval(), but it is very
> difficult to move on from there.  The lack of support given to the people
> brave or dumb enough to spend time working up a core completely from scratch
> is disheartening.

I'm not sure what can be done about this problem.  A great virtue of MOO, that
very little is built into the server, is also a problem in that a lot of work
is needed to construct something useful on that basis.  My usual recommendation
to people is that they start from LambdaCore and remove the parts they don't
like or need.

> On the other hand, there is the huge LambdaCore with all of its bells and
> whistles.   I printed out all of the verbs and objects from this beast and
> ended up with *TWO LARGE* three ring document binders full of stuff.  I
> estimate over 600 pages worth of material.  Here, the task is not so much of
> building as discovering, which, hampered by any reasonable documentation on
> the Core, makes this a very hard task as well.

It is certainly the case that we need good documentation for LambdaCore.  I
have seen a draft of a LambdaCore Programmer's Manual, written by blip, geezer,
and others.  The major problem with such a manual, though, is that it will
always be critically out of date.  The only way to solve that problem, I
believe, is to keep that documentation on-line, *inside* the database itself.

Rog has started this task for the utilities objects, but *much* more needs to
be done, both in terms of writing the documentation and, as Norman points out,
in terms of making it accessible.

> Moo needs *another* core to become popular and successful with friendly
> system managers like myself who are *QUITE* willing to sacrifice CPU and
> storage to a Moo but don't have the time to either code one up from scratch
> or decipher the black box LambdaCore.  This core would contain some simple
> definitions of common verbs and objects, and maybe a few rooms.  And, of
> course, reasonable documentation.

I think that this is wrong.  I don't think that there's a lot of `fat' in
LambdaCore that can be stripped away without significantly losing essential
functionality.  The vast majority of LambdaCore is taken up with (1) the text
of the help database, and (2) the implementation of critical commands, like
`@verb', `@create', `@dig', etc.  LambdaCore contains only one room (aside from
the generic room and the editor rooms), and the newspaper is the only
non-generic `thing'.

Again, the problem I think is one of documentation, not the content of
LambdaCore.

	Pavel/Haakon

From pavel@arisia.Xerox.COM Mon Jul 29 18:28:58 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA15921; Mon, 29 Jul 91 18:28:56 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA02773; Mon, 29 Jul 91 18:24:27 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11627>; Mon, 29 Jul 1991 18:24:20 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 29 Jul 1991 18:24:09 -0700
Message-Id: <91Jul29.182409pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 29 Jul 1991 18:23:53 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Request for Comments: Exiting and continuing loops

Several people have, at different times, asked me to add C-like `break' and
`continue' statements to the MOO language.  [For those who are not C
programmers, these statements allow one to exit a loop or start the next
iteration of a loop prematurely.]  We are now in a position to do that fairly
easily, but I'd like to probe for consensus on the details.

As a ground rule, let me say that I have never liked the names that C gives to
these constructs; I much prefer the names used in Mesa: `exit' and `loop'.
This explains why the C names are not used below.

I have come up with five possible designs for this facility, listed below.

(0) Do nothing; this is not an important enough issue to justify adding more
    cruft to the programming language.

(1) Add the statement `exit;', which immediately ends the nearest enclosing
    loop, and the statement `loop;', which immediately ends the current
    iteration of the nearest enclosing loop.  It is a syntax error for the
    `exit' or `loop' statement to be inside a `fork' statement and the nearest
    enclosing loop to enclose that `fork' statement.  That is, this sort of
    construction is in error:

	for x in (y)
	  fork (10)
	    ...
	    exit;
	    ...
	  endfork
	endfor

(2) Fix the obvious problem with proposal (1): there is no way to apply `exit'
    or `loop' to a loop that isn't the nearest enclosing one.  In this case, we
    change the syntax of the two statements to `exit <identifier>;' and `loop
    <identifier>;', respectively, where the given <identifier> specifies the
    loop in question.  The only remaining issue, then, is how identifiers are
    associated with loops.  There are a number of possibilities.

    There's a fairly obvious way to identify a particular `for' loop: use the
    name of the iteration variable.  For example, in this code:

	for x in (y)
	  for i in [1..length(x)]
	    ...
	    exit x;
	    ...
	  endfor
	endfor

    the `exit' statement would terminate the outer of the two loops.

    The obvious problem with this approach is that there's no correspondingly
    easy way to specify a particular `while' loop.  One possible solution is to
    allow the programmer to give a name to a `while' loop, perhaps using this
    syntax:

	while <identifier> ( <expression> )
	  <statements>
	endwhile

(3) Don't mimic the C way of doing this at all; instead, add a way of naming
    and exiting a block of code.  For example, the following statements might
    be added:

	begin <identifier>
	  <statements>
	end

    and

	exit <identifier>;

    where the `begin' statement just serves to give a name to a particular
    block of statements and the `exit' statements immediately terminates the
    named block.  Of course, the same restriction with respect to `fork'
    statements would apply as in proposal (1).

    One could then mimic the C `break' statement by putting a `begin' block
    around the entire looping construct and the C `continue' statement by
    putting the block around the body of the loop.

(4) Add some kind of `local procedure' construct to MOO.  One could then mimic
    `break' by putting the whole loop into a procedure and using `return' to
    terminate it (programmers already do this with verbs in MOO as it is); one
    mimics `continue' by putting just the loop body in the procedure.  The
    advantage of local procedures over separate verbs is that they could
    presumably access local variables already present in the enclosing verb.  A
    disadvantage of this proposal is that it is not as easy to implement as the
    ones above.

(5) Perhaps there's some better design that I didn't think of?

Please let me know what y'all think of this issue in the very near future.
We'd like to include it in version 1.4.0 of the server, and we're more-or-less
freezing the code for 1.4.0 next Monday.

Thanks,

	Pavel/Haakon

From rjc@gnu.ai.mit.edu Mon Jul 29 21:13:21 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <rjc@gnu.ai.mit.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA16114; Mon, 29 Jul 91 21:13:19 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA05059; Mon, 29 Jul 91 21:07:07 -0700
Received: from Minos.Parc.xerox.xns by alpha.xerox.com via XNS id <11633>; Mon, 29 Jul 1991 21:07:05 PDT
Received: from geech.gnu.ai.mit.edu ([128.52.46.34]) by alpha.xerox.com with SMTP id <11633>; Mon, 29 Jul 1991 21:06:30 PDT
Received: by geech.gnu.ai.mit.edu (5.65/4.0)
	id <AA22980@geech.gnu.ai.mit.edu>; Tue, 30 Jul 91 00:06:04 -0400
X-Mailer: ELM [version 2.3 PL0]
X-Ns-Transport-Id: 08002008D0FD000E7D0A
Message-Id: <9107300406.AA22980@geech.gnu.ai.mit.edu>
Date: 	Mon, 29 Jul 1991 17:05:59 PDT
From: rjc@gnu.ai.mit.edu (Ray)
To: MOO-Cows.PARC@xerox.com
Subject: New Parser


  Recently I logged into LambdaMOO and started experimenting with
programming it. As my first project I wanted to make a bonker that
would say "user BONKs player" when used. This object can easily be done
on MUSH, and MUF. From reading the LambdaMOO docs it sounded very
powerful and flexible with very little hardcoding in the server.
Well after 30 minutes of fooling around I found out that it is
impossible to make an object like this without putting the bonk verb on
yourself or the room, or the "bonker" object MUST appear on the command line.
(I was forced to settle with "bonk player with bonker". This of course
is irritating, even more so in a D&D game where you should be able to type
"kill monster" not "kill monster with weapon". ) MOO has one weak point
that irks me and that is the server's insistence on prepackaging and
canning user input for me. I realize some people don't want to deal with
the low-level aspects of parsing, but my proposal will not affect this.

My suggestion of how to change the parser.
------------------------------------------

  Take all "comand line" parsing out of the server and put it into the
database. Each player object will have a special verb on it called
"inputfunc()". This verb will take a string exactly like the 
user types it (NO PRE-PROCESSING AT ALL). This verb (on the base player
class) will first try to call parseverbs(). Parseverbs() will be
a function (either in the server or db) that does the normal
preprocessing that MOO does now. If  no verbs are found on the player,
then inputfunc() will be called on the room (which will call parseverbs()
itself) If no verbs are found there then the players inventory and room
contents are tried (inputfunc() will be called on each)

 The bottom line is, now each object is in control of how it parses.
It can choose to call parseverbs() and do the normal stuff, or
it can implement some special code if it's own.

Example (in pseudo code)

@verb player:inputfunc this non this /* here is another thing I don't
like. There should be REAL functions which automatically put arguements
into variables */

.program player:inputfunc

if (verbparsed=parseverbs(inputstring))
    this:(verbparsed[1])(verbparsed[2..length(verbparsed)]);
  /* call verb on player */
elseif (this.location:inputfunc(inputstring)) /* exit, a match was found */
elseif /* try calling inputfunc() on each item in our contents list */
else /* try some special parsing routines */
endif

note: when inputfunc() is called on the room, it will do the same thing
     to all the contents in the room, except players

So all I have done is made the verbparsing optional as a function in
the server which returns a list (preprocessed as usual). This makes
it optional, not manditory.

Now I will program my bonker object.

.program bonker:inputfunc

args=explode(inputstring);
if (args[1]=="bonk" && args[2]!="")
   this.location:announce(caller, " BONKs ", args[2]);
else parsemyverbs(inputstring);
. 

(parsemyverbs() would be a verb on $thing which does a 
   verbparsed=parseverbs(string); caller:(verbparsed[1])(2..endofarglist):)

This method is simple. Another method with uses "templates" is still
limited. All objects will still have to depend on what the server
gives them. This could mean that there will still be instances
in which the server gets in the way. Take the typical Tiny* emulation.
If the server depended on spaces to break up the template you couldn't
emulate the @succ object=string correctly because the server
would see "object=string" as one phrase. Whereas my method you could do
a if(answer=$string_utils:match_string(source,"@succ* *=*")) and
use answer[2] and answer[3] to set the string.

So, what does everyone think?


-Ray

"STAMP OUT HARDCODING NOW!"

From @wimsey.bc.ca,@rsoft.uucp:Frank@mindlink.uucp Mon Jul 29 23:31:28 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@wimsey.bc.ca,@rsoft.uucp:Frank@mindlink.uucp>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA16219; Mon, 29 Jul 91 23:31:24 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA06835; Mon, 29 Jul 91 23:25:45 -0700
Received: from Minos.Parc.xerox.xns by alpha.xerox.com via XNS id <11556>; Mon, 29 Jul 1991 23:25:40 PDT
Received: from wimsey.bc.ca ([192.48.234.1]) by alpha.xerox.com with SMTP id <11620>; Mon, 29 Jul 1991 23:25:09 PDT
Received: by wimsey.bc.ca (/\==/\ Smail3.1.20.1 #20.25 rmail)
	id <m0k4nTf-0000SdC@wimsey.bc.ca>; Mon, 29 Jul 91 23:22 PDT
Received: by rsoft.bc.ca (/\==/\ Smail3.1.20.1 #20.26 rmail)
	id <m0k4m5t-00022qC@rsoft.bc.ca>; Mon, 29 Jul 91 21:54 PDT
X-Ns-Transport-Id: 08002008D0FD000E7DDC
Message-Id: <m0k4m5t-00022qC@rsoft.bc.ca>
Date: 	Mon, 29 Jul 1991 21:54:00 PDT
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Sender: Frank%mindlink.uucp%rsoft.uucp@wimsey.bc.ca
To: MOO-Cows.PARC@xerox.com
Subject: Re: Request for Comments: Exiting and continuing loops

I support the decision to use the names LOOP and EXIT rather than CONTINUE and
BREAK - much more intuitive.

Option (1) is by itself a nice addition, even with the lack of a way to cleanly
exit nested loops.  I've seen implementations that allowed "break 3" to break
out of three nested loops, but I've always thought that counting lines, bytes,
and loops is something that a compiler ought to do.

The BEGIN and END idea seems a little cumbersome.

> pavel@parc.xerox.com writes:
> 
>         while <identifier> ( <expression> )
>           <statements>
>         endwhile

This is an interesting idea.  Presumably there would be a similar capability
for FOR loops?

Frank.

--
___________________________________________________________________
Frank I. Reiter                UUCP:  ...!van-bc!rsoft!frank
Reiter Software Inc.       INTERNET: frank@mindlink.bc.ca (prefered)
Surrey, British Columbia             frank@rsoft.bc.ca

From ramsey@parc.xerox.com Tue Jul 30 09:52:48 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ramsey@parc.xerox.com>
Received: from alpha by palain.PARC (4.1/SMI-4.1)
	id AB18414; Tue, 30 Jul 91 09:52:47 PDT
Received: from worsel.parc.xerox.com ([13.2.116.58]) by alpha.xerox.com with SMTP id <11775>; Tue, 30 Jul 1991 09:52:02 PDT
Received: by worsel.parc.xerox.com id <33>; Tue, 30 Jul 1991 09:51:43 -0700
Message-Id: <91Jul30.095143pdt.33@worsel.parc.xerox.com>
Date: 	Tue, 30 Jul 1991 09:51:40 PDT
From: Norman Ramsey <ramsey.PARC@xerox.com>
To: pavel@parc.xerox.com
Cc: moo-cows@arisia.xerox.com
Subject: Re:  Request for Comments: Exiting and continuing loops

> there is no way to apply `exit'
> or `loop' to a loop that isn't the nearest enclosing one.

This is a very uncommon case, so DON'T introduce new cruft like named loops
and named blocks to support it.  If you feel you must support it, I suggest
you adopt the bourne shell solution: exit to exit nearest loop, exit 2 to
do the second nearest, and so on.

Have you considered supporting exit but not loop?  I could argue that this
is right (religious flame style) or that it would shut up the complaints
while adding just half as much cruft (experimentalist style).

Norman

From yduj@lucid.com Tue Jul 30 11:03:38 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA18683; Tue, 30 Jul 91 11:03:35 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA05909; Tue, 30 Jul 91 10:56:50 -0700
Received: from Cipher.Parc.Xerox.xns by alpha.xerox.com via XNS id <11776>; Tue, 30 Jul 1991 10:56:45 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11781>; Tue, 30 Jul 1991 10:44:13 PDT
Received: from boston-harbor ([192.43.175.1]) by heavens-gate.lucid.com id AA10997g; Tue, 30 Jul 91 10:40:19 PDT
Received: by boston-harbor id AA06339g; Tue, 30 Jul 91 13:46:18 EDT
X-Ns-Transport-Id: 08002008D0FD000E83A8
Message-Id: <9107301746.AA06339@boston-harbor>
Date: 	Tue, 30 Jul 1991 10:46:18 PDT
From: Judy Anderson <yduj@lucid.com>
To: moo-cows.PARC@xerox.com
Subject: Comments in code

This is a re-send; I originally sent to moo-cows@arisia.xerox.com and
received neither my message nor a bounce.  Sigh.

Someone complained that deleting comments on input to .program was a
bad idea.  Note that comments *can* still be inserted in code, by
simply having a statement that is only a text string.  It takes zero
ticks to execute, returns a value that nobody looks at, and is
generally benign.  Rather a lot of verbs have header comments of this
type at the top (and you can say help object:verb to read them if they
exist!), and some verbs have such comments inline.  I personally never
use comments of the form /* */ precisely because I agree that comments
are not just for me in my private backup of my verbs, but are also for
any MOOers who may be reading those verbs.

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'


From crew@neon.stanford.edu Tue Jul 30 15:48:03 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19369; Tue, 30 Jul 91 15:47:59 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA21598; Tue, 30 Jul 91 15:40:47 -0700
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11809>; Tue, 30 Jul 1991 15:40:42 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA01154; Tue, 30 Jul 91 15:40:36 -0700
Message-Id: <9107302240.AA01154@Neon.Stanford.EDU>
In-Reply-To: Your message of Mon, 29 Jul 91 18:23:53 -0700.
             <91Jul29.182409pdt.58369@lambda.parc.xerox.com> 
X-Date: Mon, 29 Jul 91 20:43:03 PST
Date: 	Tue, 30 Jul 1991 15:40:35 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Request for Comments: Exiting and continuing loops 


[ hmm... my mail seems to have been dropped on the floor, too.
  Just as well, since now I can edit it some more.
  Apologies if you got subjected to the earlier version of this...]

Re (1) & (2):

>   As a ground rule, let me say that I have never liked the names
>   that C gives to these constructs; I much prefer the names used in
>   Mesa: `exit' and `loop'.  This explains why the C names are not
>   used below.

When I see `loop' I tend to think of it in the Modula sense
of *beginning* a loop (Modula has a construct `loop ... end' which is 
essentially a synonym for `while (1) ... endwhile').
If you do end up going with (1) or (2), 
I'll suggest  `next' as being more descriptive, e.g.,

   	for x in (y)
   	  for i in [1..length(x)]
   	    ...
   	    next x;
   	    ...
   	  endfor
   	endfor

[ Yes, Rog admits to programming in BASIC in his misbegotten youth...]

Re (3) begin foo ...exit foo... end

This one has the potential to be seriously abused.
Quick question:  what's the difference between

   begin foo             label foo; 
     .1.                 .1.       
     exit                goto foo; 
     .2.                 .2.       
   end              foo: .3.            
   .3.                                 

where the `goto' construct is supplied with the usual proviso that you
can't jump *into* anything (loop bodies, fork bodies if-else clauses)...  ?
Answer:  the one on the left looks slightly prettier.

Figure if you're going to go this route, you should probably do it as 
`catch' and `throw', and then do them in full generality.  That is,
allow `throw' (i.e., what you call `exit') to exit from inside a called verb 
(i.e., return several levels up the stack at once...), 
allow it to pass a return value, and then merge in the error 
handling (i.e., so that an error is really doing a `throw error=E_WHATEVER').
The latter would allow putting `catch error ... endcatch' around a particular 
piece of code, rather than having to turn off the `d' flag for the 
entire verb.   

This would probably satisfy the folks that don't want to see the
language grow too much, since there's a lot of mileage to be had from 
this one construct.
However, being as it is a generalization of the begin... exit ...end proposal,
it also has the potential to be seriously abused.
There's also this Small Matter of Programming, too... :-(

Re: (4) nested function definitions

This could be justified on entirely different grounds, e.g., consider the
situations where one wants to be able to traverse some recursive
structure and do it without having to define an auxiliary verb.

However, having function definitions locked away inside of other verbs 
seems somewhat at odds with object-orientedness IMHO.... i.e., in the
sense that one should encourage having lots of little, exposed verbs 
rather than a few big monolithic verbs with lots of nested definitions.
I think that once we get to the point of being able to specify actual 
argument lists for verbs so that using auxiliary verbs becomes that
much less cumbersome, the need for nested function definitions should 
more or less go away.
 - - -
 
I'll put in a vote for (2).  As for the issue of adding cruft, 
it's useful cruft; nearly every language that supplies loops supplies 
some sort of escape mechanism.

--
Roger Crew
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MUD:       Rog@LambdaMOO

From sfwhite@watcgl.waterloo.edu Tue Jul 30 17:15:44 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA19639; Tue, 30 Jul 91 17:15:41 PDT
Received: from watcgl.waterloo.edu ([129.97.140.64]) by alpha.xerox.com with SMTP id <11829>; Tue, 30 Jul 1991 17:14:51 PDT
Received: by watcgl.waterloo.edu
	id <AA11048>; Tue, 30 Jul 91 20:14:27 -0400
Message-Id: <9107310014.AA11048@watcgl.waterloo.edu>
Date: 	Tue, 30 Jul 1991 17:14:27 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: moo-cows@arisia.xerox.com, pavel@parc.xerox.com
Subject: Re:  Request for Comments: Exiting and continuing loops

moo 2.0 has break and continue statements.  they use the format:

break [<count>] ;
continue [<count>] ;

the count indicates how many loops are to be exited/continued, so
"break;" is equivalent to "break 1;".  this isn't the prettiest
solution, of course.

-- stephen/ghond

From pavel@arisia.Xerox.COM Tue Jul 30 18:08:00 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA19723; Tue, 30 Jul 91 18:07:58 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA23781; Tue, 30 Jul 91 18:01:24 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11841>; Tue, 30 Jul 1991 18:01:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11835>; Tue, 30 Jul 1991 18:00:25 PDT
Received: by lambda.parc.xerox.com id <58369>; Tue, 30 Jul 1991 18:00:07 -0700
X-Ns-Transport-Id: 08002008D0FD000E8972
Message-Id: <91Jul30.180007pdt.58369@lambda.parc.xerox.com>
Date: 	Tue, 30 Jul 1991 18:00:05 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows.PARC@xerox.com
Subject: Mail problems with MOO-Cows

Several people have told me that they're having problems with sending mail to
the MOO-Cows mailing list, especially with replying to mail they receive on the
list.  Let me explain the problem and the workaround.

MOO-Cows mail goes through a machine named `arisia.xerox.com', which contains
the actual file listing all of the addresses on the list.  That machine, unlike
the vast majority of machines here, is generally accessible from non-Xerox
machines.  Well, it *was* accessible.

A couple of weeks ago, we discovered that arisia was under attack from outside
`crackers', computer vandals.  As a result of that discovery, access to arisia
from outside was essentially cut off, including in-bound mail delivery.

The way that mail works around Xerox makes for a long and messy story, so let
me jump straight to the punchline: mail to the MOO-Cows list should go to

	MOO-Cows@Xerox.Com

and *not* to

	MOO-Cows@Arisia.Xerox.Com

The first form essentially routes the mail to arisia *from inside Xerox*, so it
works.  The second form tries to go directly to arisia, so it fails.

This would be easy to work with were it not for the fact that arisia *insists*
on rewriting the mail so that it looks like all messages were sent to
`arisia.xerox.com'.  Thus, if you simply reply to a MOO-Cows posting, your
mailer will end up using the failing address; you must change that address
manually to the working one above.

There is, however, some hope in this otherwise ugly picture: arisia is being
retired and replaced by a machine that will get a lot more support and
maintainance, probably within the next month.  After that, I hope that it will
become a lot easier to cope with MOO-Cows, both for you all and for me.

Until then, thank you for your patience...

	Pavel/Haakon

From scott@suna0.cs.uiuc.edu Wed Jul 31 07:19:02 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <scott@suna0.cs.uiuc.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA20613; Wed, 31 Jul 91 07:18:58 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA02603; Wed, 31 Jul 91 07:04:41 -0700
Received: from Minos.Parc.xerox.xns by alpha.xerox.com via XNS id <11731>; Wed, 31 Jul 1991 07:04:34 PDT
Received: from sunc5.cs.uiuc.edu ([128.174.244.85]) by alpha.xerox.com with SMTP id <11723>; Wed, 31 Jul 1991 07:03:43 PDT
Received: by sunc5.cs.uiuc.edu id AA10139
  (5.65b/IDA-1.4.3 for MOO-Cows@Xerox.COM); Wed, 31 Jul 91 09:03:38 -0500
X-Ns-Transport-Id: 08002008D0FD000E8E2C
Message-Id: <9107311403.AA10139@sunc5.cs.uiuc.edu>
Date: 	Wed, 31 Jul 1991 07:03:38 PDT
From: Jay Scott <scott@suna0.cs.uiuc.edu>
To: MOO-Cows.PARC@xerox.com
Subject: Re: exit loop

[This is a resend, courtesy of Friendly Arisia.]

I vote for proposal (0.5): Have 'exit' exit from the innermost loop. I
think 'loop' costs more cognitive overhead than it's worth.

	Frand
	scott@cs.uiuc.edu

From mjp@hplb.hpl.hp.com Fri Aug  2 12:07:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <mjp@hplb.hpl.hp.com>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA26894; Fri, 2 Aug 91 12:07:37 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA24178; Fri, 2 Aug 91 11:50:02 -0700
Received: from Minos.Parc.xerox.xns by alpha.xerox.com via XNS id <12048>; Fri, 2 Aug 1991 11:49:58 PDT
Received: from hplb.hpl.hp.com ([15.255.59.2]) by alpha.xerox.com with SMTP id <11832>; Fri, 2 Aug 1991 11:16:21 PDT
Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Fri, 2 Aug 91 09:11:12 +0100
Received: by prudence.hpl.hp.com with SMTP
	(15.11/15.6+ISC) id AA02697; Fri, 2 Aug 91 09:13:49 bst
X-Ns-Transport-Id: 08002008D0FD000EA8F2
Message-Id: <9108020813.AA02697@prudence.hpl.hp.com>
Date: 	Fri, 2 Aug 1991 01:13:48 PDT
From: Mike Prudence <mjp@hplb.hpl.hp.com>
To: MOO-cows.PARC@xerox.com
Subject: Manuals and stuff

Hi Folks,

Unfortunately for me, the long message I mailed out to the MOO-Cows
list in response to the recent 'documentation' discussion disappeared
into the aether as a result of the mailing list problems.

Anyways, here's the gist.

As Pavel mentioned, I and a few other guys here at HP have been
working on a couple of manuals for LambdaMOO (the program, not the
MUD).

For a while now, I've been running a small TinyMUCK here.  After
catching wind of MOO, I took a look, and decided we would gain a lot
by moving over.  I got together a small team, and we're busily putting
together a nice little world to open up to the HP public some time
next year.

Having decided to base our stuff on the LambdaCore database, our first
problem was understanding what the hell was going on.  As somebody has
said, it is very difficult to write a MOO program unless, for example,
you know that $player:tell() is the verb to use to send a message to
your player's screen.

In order to prevent every single HP MOOer from going through the
tedious @list'ing of every verb in the database, I started documenting
the core DB that we are based on - the most current one available with
the LambdaMOO server distribution.  I resisted the temptation to
document any additions we have made (such as HUH logging, and a few
tweaks that seem to be paralleled in Lambda) simply so that other
people *outside of LambdaMOO (the MUD)* could take the server,
LambdaCore and my docs as a complete package that would allow them to
set their own MUD up.

Looking at it from that point of view, one can argue that the docs I
have done will be largely useless for anyone playing LambdaMOO (the
MUD), becuase they will always be hopelessly out of date.

However, for someone who is setting up their own MOO, having docs that
describe the snapshot they are going to be working with is essential.

Documentation is a big thing with our development team, but we are
keeping our MUD specific docs separate from the general LambdaCore
docs just so that other people can make use of what we've done.  I
have always been a great fan of software re-use.

At the moment, there are two manuals: "The LambdaCore Database Users'
Manual", which is essentially the help text presented in a nice format
with an index; and "The LambdaCore Database Programmers' Manual",
which covers the innards of the database in gritty detail.

The former is complete.  The latter is almost complete.  To be honest,
I got fed up with puzzling over cryptic code with very few comments
(although the later stuff is a lot better, from what I can tell - full
marks to the Lambda folks) and so some odds like the Mail Room and
Editor classes are not documented.  However, the core classes and the
utilities are all there, and this has already proven itself to our
team as an invaluable reference.

I am prepared to release these docs to the people on this list, mostly
so that I can 

   o get some feedback, and help in correcting the errors that I will
     have made.  And there will be a lot of them :)

   o possibly get some extra text to incorporate, be it the missing
     sections from the programmer's manual, or some examples, hints, tips
     etc.

If someone can point me to a suitable ftp site to plonk the two files,
I will happily oblige.  Then let the comments come pouring in !!

Cheers,

Mike

mjp@hplb.hpl.hp.com

From joe@dot.unipress.com.unipress Fri Aug  2 14:16:19 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <joe@dot.unipress.com.unipress>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA27579; Fri, 2 Aug 91 14:16:16 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA26833; Fri, 2 Aug 91 14:10:46 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11636>; Fri, 2 Aug 1991 14:10:39 PDT
Received: from rutgers.edu ([128.6.21.9]) by alpha.xerox.com with SMTP id <11646>; Fri, 2 Aug 1991 14:09:47 PDT
Received: from unipress-link.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
	id AA13570; Fri, 2 Aug 91 17:09:19 EDT
Received: from dot.unipress.com.unipress by repo.unipress.com.unipress (4.1/SMI-4.1)
	id AA04756; Fri, 2 Aug 91 16:32:55 EDT
Received: by dot.unipress.com.unipress (4.1/SMI-4.1)
	id AA13057; Fri, 2 Aug 91 16:36:51 EDT
X-Ns-Transport-Id: 08002008D0FD000EB013
Message-Id: <9108022036.AA13057@dot.unipress.com.unipress>
Date: 	Fri, 2 Aug 1991 13:36:51 PDT
From: joe@dot.unipress.com.unipress (Technomystic at large.)
To: MOO-cows.PARC@xerox.com

Subject: Re: Request for Comments: Exiting and continuing loops

> I have come up with five possible designs for this facility, listed
> below.

> (0) Do nothing ...

Nah.  Do something.

> (1) Add the statement `exit;', which immediately ends the nearest
> enclosing loop, and the statement `loop;', which immediately ends
> the current iteration of the nearest enclosing loop.  It is a syntax
> error for the `exit' or `loop' statement to be inside a `fork'
> statement and the nearest enclosing loop to enclose that `fork'
> statement.

This would do quite nicely, keeping Moo's kind attitude toward C
programmers intact.  For most of the Moo stuff I've seen, this would
be just enough leverage.

> (2) Fix the obvious problem with proposal (1): there is no way to
> apply `exit' or `loop' to a loop that isn't the nearest enclosing
> one.  ...

Instead of any of the possibilities you listed, I'd prefer a goto
statement (which wouldn't work out of forks, etc.), again, to keep the
Moo language similar to C.  Furthermore, there's no point in piling up
the order of the D structures, you may as well go straight to L
structures since D(N) structures and L structures are semanticly
equivalent anyway.  (It's been a while since I've studied D and L
structures, so forgive me if I just got that wrong :-})

> (3) Don't mimic the C way of doing this at all; instead, add a way
> of naming and exiting a block of code.  ... Of course, the same
> restriction with respect to `fork' statements would apply as in
> proposal (1).

This is actually kinda like a fancy goto.  Why not go all the way and
implement lambda? ...

> (4) Add some kind of `local procedure' construct to MOO.  ...

... oh, you already thought of that (?).

> (5) Perhaps there's some better design that I didn't think of?

Well, I've seen better control flow structures than those in C (namely
Scheme's call-with-current-continuation), but I don't think Moo really
needs that kind of industrial strength.

I'm happy with (1).  The Moo language is Cish already, may as well
keep it so.  (1) with C's goto would be even finer.

I eagerly await the next release.

--joe (AKA Khalarghast)		joe@dot.unipress.com

From 054340@acadvm1.uottawa.ca Fri Aug  2 14:27:12 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <054340@acadvm1.uottawa.ca>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA27616; Fri, 2 Aug 91 14:27:05 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA27119; Fri, 2 Aug 91 14:22:32 -0700
Received: from Cipher.Parc.Xerox.xns by alpha.xerox.com via XNS id <11636>; Fri, 2 Aug 1991 14:22:23 PDT
Received: from acadvm1.uottawa.ca ([137.122.6.6]) by alpha.xerox.com with SMTP id <12067>; Fri, 2 Aug 1991 12:06:59 PDT
Received: from ACADVM1.UOTTAWA.CA by acadvm1.uottawa.ca (IBM VM SMTP R1.2.2MX) with BSMTP id 6197; Fri, 02 Aug 91 15:07:55 EDT
Received: by UOTTAWA (Mailer R2.07) id 3636; Fri, 02 Aug 91 15:07:54 EDT
X-Ns-Transport-Id: 08002008D0FD000EABDE
Message-Id: <91Aug2.120659pdt.12067@alpha.xerox.com>
Date: 	Fri, 2 Aug 1991 11:59:31 PDT
From: Matthew Simpson <054340%UOTTAWA@acadvm1.uottawa.ca>
Sender: 054340@acadvm1.uottawa.ca
To: MOO-cows.PARC@xerox.com

Hats off to Mike Prudence.  The kind of thing he is doing on his own initiative
might be the kind of thing that could help people like me and this idea I will
present now.

I would like to see LambdaMOO (program) be used to design a conference center
for people in the field of psychology.  However, here is the problem.  I can
learn to @dig, @create, and @describe the place in detail.  However, I am not
a person in the field of computer science.  I study psychology.  This system
would be fantastic for the American Psychological Association (APA) and the
Canadian Psychological Association (CPA) and many other associations to
use for conferencing.  I do not know what would be required.

Could a computer novice use the software to do such a thing?  Or is it the
case that this type of undertaking is far out of the reach of a person like
me?  Is it simple?  Or, is it incredibly complicated so that only people
trained in computer science can set it up?

Thank you for your time and attention, today.
Matthew Simpson


From @vaxb.acs.unt.edu:cluther@morticia.cnns.unt.edu Fri Aug  2 15:09:18 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@vaxb.acs.unt.edu:cluther@morticia.cnns.unt.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA27736; Fri, 2 Aug 91 15:09:12 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA27927; Fri, 2 Aug 91 15:02:05 -0700
Received: from Minos.Parc.xerox.xns by alpha.xerox.com via XNS id <11526>; Fri, 2 Aug 1991 15:02:04 PDT
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11673>; Fri, 2 Aug 1991 15:00:58 PDT
Received: by sonne (4.1/1.36)
	id AA05819; Fri, 2 Aug 91 16:53:50 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD000EB0C6
Message-Id: <9108022153.AA05819@sonne>
Date: 	Fri, 2 Aug 1991 14:53:48 PDT
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@arisia.Xerox.COM (Moo Cows)
Subject: Moo 2.0a and LCore 1.3.0

Um, why won't Moo2.0a read Lcore 1.3.0?


-- 
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               ** Always question authority **

From sfwhite@watcgl.waterloo.edu Fri Aug  2 15:48:24 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA27861; Fri, 2 Aug 91 15:48:20 PDT
Received: from watcgl.waterloo.edu ([129.97.140.64]) by alpha.xerox.com with SMTP id <11547>; Fri, 2 Aug 1991 15:47:32 PDT
Received: by watcgl.waterloo.edu
	id <AA03987>; Fri, 2 Aug 91 18:47:14 -0400
Message-Id: <9108022247.AA03987@watcgl.waterloo.edu>
Date: 	Fri, 2 Aug 1991 15:47:14 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: MOO-cows@xerox.com, pavel@parc.xerox.com
Subject: Re:  Request for Comments: Exiting and continuing loops

moo 2.0 has break and continue statements.  they use the format:

break [<count>] ;
continue [<count>] ;

the count indicates how many loops are to be exited/continued, so
"break;" is equivalent to "break 1;".  this isn't the prettiest
solution, of course.

> for i in [1..length(x)]

oh yeah, that reminds me.  one change to array subsets in 2.0 which
you might like to use is:

x[a..]  means  x[a..length(x)],
x[..b]  means  x[1..b]

this wouldn't apply in for loops, obviously.

-- stephen/ghond

From pavel@arisia.Xerox.COM Fri Aug  2 17:51:13 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA28278; Fri, 2 Aug 91 17:51:12 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA29846; Fri, 2 Aug 91 17:47:04 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11689>; Fri, 2 Aug 1991 17:47:02 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 2 Aug 1991 17:45:56 -0700
In-Reply-To: <9108022153.AA05819@sonne>
Message-Id: <91Aug2.174556pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 2 Aug 1991 17:45:48 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu
Cc: moo-cows@arisia.Xerox.COM
Subject: Re: Moo 2.0a and LCore 1.3.0

Clay Luther writes:
> Um, why won't Moo2.0a read Lcore 1.3.0?

Um, because Moo2.0a is a version of ghond's MOO, not of LambdaMOO.  LambdaMOO
is derived from the beta-release sources for MOO 1.0.  I believe that ghond
started more-or-less completely from scratch in writing Moo 2.  Is that
correct, ghond?

	Pavel

From pavel@arisia.Xerox.COM Fri Aug  2 17:51:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA28287; Fri, 2 Aug 91 17:51:43 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA29855; Fri, 2 Aug 91 17:47:50 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11696>; Fri, 2 Aug 1991 17:47:43 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 2 Aug 1991 17:47:27 -0700
In-Reply-To: <9108022247.AA03987@watcgl.waterloo.edu>
Message-Id: <91Aug2.174727pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 2 Aug 1991 17:47:21 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: sfwhite@watcgl.waterloo.edu
Cc: moo-cows@arisia.Xerox.COM
Subject: Re:  Request for Comments: Exiting and continuing loops

Stephen White writes:
> oh yeah, that reminds me.  one change to array subsets in 2.0 which
> you might like to use is:
> 
> x[a..]  means  x[a..length(x)],
> x[..b]  means  x[1..b]
> 
> this wouldn't apply in for loops, obviously.

I thought of that, too.  Perhaps we'll toss it into version 1.4.0...

	Pavel

From ramsey@parc.xerox.com Fri Aug  2 17:58:59 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ramsey@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA28295; Fri, 2 Aug 91 17:58:58 PDT
Received: from worsel.parc.xerox.com ([13.2.116.58]) by alpha.xerox.com with SMTP id <11696>; Fri, 2 Aug 1991 17:58:06 PDT
Received: by worsel.parc.xerox.com id <33>; Fri, 2 Aug 1991 17:57:46 -0700
Message-Id: <91Aug2.175746pdt.33@worsel.parc.xerox.com>
Date: 	Fri, 2 Aug 1991 17:57:41 PDT
From: Norman Ramsey <ramsey@parc.xerox.com>
To: pavel@parc.xerox.com, sfwhite@watcgl.waterloo.edu
Cc: moo-cows@arisia.xerox.com
Subject: Re:  Request for Comments: Exiting and continuing loops

> > oh yeah, that reminds me.  one change to array subsets in 2.0 which
> > you might like to use is:
> > 
> > x[a..]  means  x[a..length(x)],
> > x[..b]  means  x[1..b]
> > 
> > this wouldn't apply in for loops, obviously.

> I thought of that, too.  Perhaps we'll toss it into version 1.4.0...

Gentlemen, gentlemen, please!  Not more syntax!  You should be looking
for features to take out, not features to add (1/2 :-)

Norman

From sfwhite@watcgl.waterloo.edu Sat Aug  3 00:34:17 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA28702; Sat, 3 Aug 91 00:34:14 PDT
Received: from watcgl.waterloo.edu ([129.97.140.64]) by alpha.xerox.com with SMTP id <11700>; Sat, 3 Aug 1991 00:33:26 PDT
Received: by watcgl.waterloo.edu
	id <AA16159>; Sat, 3 Aug 91 03:33:03 -0400
Message-Id: <9108030733.AA16159@watcgl.waterloo.edu>
Date: 	Sat, 3 Aug 1991 00:33:03 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu, pavel@parc.xerox.com
Cc: moo-cows@arisia.xerox.com
Subject: Re: Moo 2.0a and LCore 1.3.0

Clay Luther writes:
>> Um, why won't Moo2.0a read Lcore 1.3.0?

pavel sez:
> Um, because Moo2.0a is a version of ghond's MOO, not of LambdaMOO.  LambdaMOO
> is derived from the beta-release sources for MOO 1.0.  I believe that ghond
> started more-or-less completely from scratch in writing Moo 2.  Is that
> correct, ghond?

uhh, not quite.  it was a fairly major rewrite, though.

believe it or not, there was another (alpha) release before the beta
sources that pavel used.  it was incredibly limited (compile-time
searching for properties, no lists, no verb calling).  sometimes
i wonder if all the bells and whistles have really improved the
"fun" quotient that much.  they've certainly made things complicated
(even *i* have trouble predicting the permissions system sometimes..)

-- stephen/ghond

From @vaxb.acs.unt.edu:cluther@morticia.cnns.unt.edu Sat Aug  3 09:03:35 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <@vaxb.acs.unt.edu:cluther@morticia.cnns.unt.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA29058; Sat, 3 Aug 91 09:03:32 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA06133; Sat, 3 Aug 91 08:52:15 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11716>; Sat, 3 Aug 1991 08:50:58 PDT
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11717>; Sat, 3 Aug 1991 08:50:26 PDT
Received: by sonne (4.1/1.36)
	id AA06482; Sat, 3 Aug 91 10:43:06 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD000EB59E
Message-Id: <9108031543.AA06482@sonne>
Date: 	Sat, 3 Aug 1991 08:43:04 PDT
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@arisia.Xerox.COM (Moo Cows)
Subject: Re:  Request for Comments: Exiting and continuing loops (fwd)

> > > oh yeah, that reminds me.  one change to array subsets in 2.0 which
> > > you might like to use is:
> > > 
> > > x[a..]  means  x[a..length(x)],
> > > x[..b]  means  x[1..b]
> > > 
> > > this wouldn't apply in for loops, obviously.
> 
> > I thought of that, too.  Perhaps we'll toss it into version 1.4.0...
> 
> Gentlemen, gentlemen, please!  Not more syntax!  You should be looking
> for features to take out, not features to add (1/2 :-)
> 
> Norman
> 

Norman and I are of the same mind!  Yes, Pavel, Moo (and Lambda, especially)
are showing signs of creeping featurism.

Ugh.

-- 
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               ** Always question authority **

From crew@neon.stanford.edu Sat Aug  3 17:01:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA29474; Sat, 3 Aug 91 17:01:50 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA13774; Sat, 3 Aug 91 16:55:46 -0700
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11730>; Sat, 3 Aug 1991 16:55:39 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA11609; Sat, 3 Aug 91 16:55:32 -0700
Message-Id: <9108032355.AA11609@Neon.Stanford.EDU>
In-Reply-To: Your message of Sat, 03 Aug 91 08:43:04 -0700.
             <9108031543.AA06482@sonne> 
X-Date: Sat, 3 Aug 91 15:22:20 PST
Date: 	Sat, 3 Aug 1991 16:55:32 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: Moo Cows <moo-cows@arisia.Xerox.COM>
Subject: Re: Request for Comments: Exiting and continuing loops (fwd) 

>> Gentlemen, gentlemen, please!  Not more syntax!  You should be looking
>> for features to take out, not features to add (1/2 :-)
>
>  Norman and I are of the same mind!  Yes, Pavel, Moo (and Lambda, especially)
>  are showing signs of creeping featurism.

You're right, of course.  Now that I think about it, let's get rid of
FOR loops.  After all, you can do the same thing with WHILE.  In fact,
let's get rid of WHILE, too, since you can accomplish everything WHILE
does with recursion.  As for this whole x[a..]==x[a..length(x)]
silliness, let's go the whole route and abolish the length() function.
After all we can easily write a verb to try various indices to see
where we get an E_RANGE error...

Let's get rid of all of these useless FEATURES.   :-)

All kidding aside, I'll agree that [..x]==[1..x] is pointless unless
one is planning to introduce non-1-based arrays.
I'll also admit to being slightly annoyed at various MOOisms
(e.g., the existence of {@foo,},listappend(),and listinsert() to all 
do the same thing).  
And yes, I'll admit that TNT is completely gratuitous...

...but as for foo[y..length(foo)]==foo[y..], this was actually near
the top of the list of suggestions I was about to make myself, the
only reason I hadn't was that I had yet to come with a good readable
syntax for it and was holding out for some reasonable way to do 
foo[n..length(foo)-k]...  In any case this buisiness of grabbing the 
tail of a string or list comes up all over the place.  Getting rid of the
cumbersome [k..length(foo)] construct would enhance readability, and
it's an easy change to make, ...it even saves a tick.  So what's the problem?

In fact, you *can* extend this to FOR loops, too.  
If you think of `for i in [***]' as being shorthand for 
`for i in (natural_numbers[***])' it even makes sense to do so.

In this view

  for i in [n..] 
    *** 
  endfor

is equivalent to 

  i=n; 
  while(1) 
    *** 
    i=i+1; 
  endwhile

and moreover, it would be USEFUL (especially once we have an `exit' facility).
I've already written at least one `for i in [1..2147483647]' loop.
Doing it as a while costs two extra ticks each time through, which
makes a *big* difference on long lists, not to mention the hazard 
that with a large enough loop body, one might forget to put in the 
i=i+1 at the end, also not to mention the nonportability of having to
put maxint in there explicitly...

Actually, if there were a decent macro facility, most of my arguments
would be moot, but then I suspect *that* cure might viewed by some as
worse than the disease.

	Roger

PS.  Re `exit 2', `exit 3' `loop/next 5':  ... ummm.  
I get confused whenever I try to count higher than 1, honest; 
I'd like to think that a 10+ MIPS workstation can do some of my counting 
for me.  Use labels, *please*.

From crew@neon.stanford.edu Sat Aug  3 19:01:09 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA29566; Sat, 3 Aug 91 19:01:06 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA14660; Sat, 3 Aug 91 18:56:09 -0700
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11745>; Sat, 3 Aug 1991 18:56:02 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA14831; Sat, 3 Aug 91 18:55:52 -0700
Message-Id: <9108040155.AA14831@Neon.Stanford.EDU>
In-Reply-To: Your message of Mon, 29 Jul 91 18:23:53 -0700.
             <91Jul29.182409pdt.58369@lambda.parc.xerox.com> 
X-Date: Sat, 3 Aug 91 17:53:44 PST
Date: 	Sat, 3 Aug 1991 18:55:51 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Request for Comments: Exiting and continuing loops 

While we're on the subject, I just noticed something interesting:

  for i in [1..5]           for x in ({"fee","fi","fo"})
  endfor                    endfor
  return i;                 return x;
   => 5                      => "fo"

IMHO, these are wrong no matter how you look at it.
Suggestions for how to handle the loop variable when it occurs 
beyond the loop body and there's been no intervening assignment:

1) Undefined, 
   i.e., both of the above expressions should have barfed back at me with
   E_VARNF ("Variable not found")

2) If one is going to have abnormal exits from loops and the loop variable
   *is* going to have an actual value, then it's important that this value
   be meaningful.  The suggestion here is that one be able to use it to
   distinguish between normal and abnormal exits.  The obvious value for an
   abnormal exit is the value it had at the point of exit.  This suggests
   that `for i in [a..b]' should set i to something not in the range [a..b]
   on a normal exit; b+1 would do nicely (6, in the above example).

   As for the `for e in ({"fee","fi","fo"})' loop, one could analogously have 
   e set upon normal exit to the element of the list that might be thought of
   as following the final one, "fo", namely E_RANGE.

   2a) always set the loop variable to E_RANGE on a normal exits, 
       even with `for i in [a..b]'

   2b) make up a new error value and use that instead of E_RANGE.

3) The loop variable has an actual value iff the loop exits abnormally.
   Otherwise, referring to it raises E_VARNF (or E_RANGE).  
   This is most in keeping with current MOO-server practice (w.r.t. always 
   raising errors and never just returning them), but could be annoying in 
   that it will require people to unset 'd' if they want to make use of it.

--
Roger Crew
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MUD:       Rog@LambdaMOO

From mjp@hplb.hpl.hp.com Mon Aug  5 07:55:41 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <mjp@hplb.hpl.hp.com>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA01444; Mon, 5 Aug 91 07:55:37 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01715; Mon, 5 Aug 91 07:50:32 -0700
Received: from hplb.hpl.hp.com ([15.255.59.2]) by alpha.xerox.com with SMTP id <11613>; Mon, 5 Aug 1991 07:50:25 PDT
Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Tue, 30 Jul 91 18:13:41 +0100
Received: by prudence with SMTP
	(15.11/15.6+ISC) id AA19861; Tue, 30 Jul 91 18:16:37 bst
Message-Id: <9107301716.AA19861@prudence>
Date: 	Tue, 30 Jul 1991 10:16:36 PDT
From: Mike Prudence <mjp@hplb.hpl.hp.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Impressions of a new MOOer

Hi all,

Recently regarding Pavel Curtis <pavel@parc.xerox.com> said:

> It is certainly the case that we need good documentation for
> LambdaCore.  I have seen a draft of a LambdaCore Programmer's Manual,
> written by blip, geezer, and others.  The major problem with such a
> manual, though, is that it will always be critically out of date.  The
> only way to solve that problem, I believe, is to keep that
> documentation on-line, *inside* the database itself.

As my name was mentioned, I'll add my 2p worth :)

I think I can see both sides of this 'discussion', and I think the
problem is one of viewpoint.  From Haakon's point of view, LambdaMOO
is the central entity that he is concerned with, and this is a very
dynamic and rapidly changing database.  Documenting such a system is
not, as Haakon points out, a feasible idea.

On the other hand, from the point of view of other sys admins who want
to start up their own MOO, a document such as this is a necessity.  I
started up a MOO here at Hewlett Packard to replace a small MUCK that
I used to run.  I got together a small team to work on the details,
and we intend to build some interesting areas, and then open up to the
general HP public.

Our problem was the incredible learning curve associated with taking
the server and a core snapshot, and trying to build a game out of it.
The only way I saw of stopping everyone going through the same tedious
hours of @list'ing was to produce a document of the core we were
using.

It turned out into two documents - one basically a hard copy of the
'help' text, and the other a detailed, blow by blow account of every
verb in the database, hopefully spotting the interfaces involved, and
the things you need to know to write effective programs in MOO.  I
resisted the temptation to put in the extra things we have added to
our DB, feeling that this document, placed with the current snapshot,
would be invaluable to anyone else who is starting up their own MOO.

I don't see it as being all that useful to people playing LambdaMOO,
for the reasons that Haakon mentioned above.

So where do you get hold of these manuals ?  Well, as
belch.berkeley.edu is losing its status as a mud fount of ftp
knowledge, I'm not sure where to put these for people to grab.  The
programmer's manual is not complete - I got so chronically bored by
the prospect of documenting the mail room, verb editor etc that I put
it on hold, but the core classes and the utilities are all done.  If
anyone wants to volunteer to document the missing bits, let me know.

Cheers,

Mike

mjp@hplb.hpl.hp.com     "Anagrams(1) : Hewlett Packard => pedal that wreck"


From pavel@arisia.Xerox.COM Fri Aug  9 18:03:23 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03557; Fri, 9 Aug 91 18:03:21 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA24448; Fri, 9 Aug 91 17:54:21 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11987>; Fri, 9 Aug 1991 17:43:53 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 9 Aug 1991 17:43:44 -0700
Message-Id: <91Aug9.174344pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 9 Aug 1991 17:43:38 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Version 1.4.0 Release Delayed

We were all set to release version 1.4.0 of the LambdaMOO server today until I
tried compiling and running it on one of our local SGI Iris machines, which use
the same compiler and processor as the popular DEC MIPS machines on which
several people want to run LambdaMOO.  After the usual horsing around removing
uses of valid ANSI C programming constructs (because the MIPS compiler does not
support them), I managed to get a clean compilation.  The compiled server,
however, would not run.

With some effort, I was able to track the trouble down to a serious bug in the
MIPS compiler's implementation of variable-number-of-arguments procedures.  I
believe that I know how to work around the bug sufficiently to make this
release work on such a machine, but I no longer have enough time today to
effect the fix and test it.

As I am going on vacation for the next week, this means that the release of
1.4.0 will be delayed until sometime in the week beginning August 19th.  This
will give us more time to shake out bugs, since the new server is currently in
use on the original LambdaMOO, so it's not all bad I suppose.

	Pavel

From pavel@arisia.Xerox.COM Thu Aug 22 15:44:49 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA06595; Thu, 22 Aug 91 15:44:47 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA08138; Thu, 22 Aug 91 15:38:10 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11712>; Thu, 22 Aug 1991 15:36:46 PDT
Received: by lambda.parc.xerox.com id <58369>; Thu, 22 Aug 1991 15:36:31 -0700
Message-Id: <91Aug22.153631pdt.58369@lambda.parc.xerox.com>
Date: 	Thu, 22 Aug 1991 15:36:16 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: LambdaMOO server version 1.4.0 released!

Version 1.4.0 of the LambdaMOO server has been released and is now available
for anonymous FTP from `parcftp.xerox.com' in `pub/MOO/LambdaMOO-1.4.0.tar.Z'.

[Note: I am no longer using the FTP site `watnxt3.ucr.edu'; the greater control
       provided by using a local site is significant.]

I hope to release an updated version of the programmer's manual later today and
an up-to-date LambdaCore database today or tomorrow.

	Pavel

Here's the change log for this version:

-- Fixed a bug whereby running out of seconds might be misreported as running
   out of ticks.
-- Fixed a bug whereby using `@' on a non-list in a verb's argument list could
   end up passing E_TYPE as the value of `args'.
-- Fixed parsing bug that would ignore an extraneous comma at the front of an
   argument list.
-- Changed random() to raise E_INVARG on non-positive numerical arguments,
   rather than E_TYPE.
-- Fixed bug in handling of the case where a verb disappears between a
   `.program' and the corresponding `.'.
-- Made it a type error to use <, <=, >, or >= either on operands of different
   types or on lists.
-- Completely rewrote the MOO-code parser, unparser, and interpreter using a
   new program representation based on vectors of bytecodes instead of abstract
   syntax trees.  This saves space and time and also allows the interpreter to
   be iterative instead of recursive.  This, in turn, allows us to implement
   various operations that involve saving the entire state of a running task
   for later resumption.
-- Added read() and suspend() functions, using the new capabilities of the
   interpreter.
-- The new interpreter counts a few more ticks than the old one; in particular,
   every IF, ELSEIF, and FORK now counts a tick.  In view of this, and in view
   of the improved performance of the interpreter, the ticks limit for tasks
   has been increased from 20,000 to 30,000.
-- Added an indexed assignment statement for updating lists stored in variables
   and properties.
-- Fixed bug in numeric comparisons where `-2147483647 > 1' was false but
   `-2147483647 > 2' was true.
-- Fixed database dumping to detect and recover from filesystem errors.  For
   normal periodic checkpoints, the dump attempt is simply abandoned.  For
   panic and shutdown dumps, the server retries the dump from the beginning
   after waiting 60 seconds (during which time, presumably, the archwizard will
   fix whatever the problem was).  In all cases, explanatory messages are
   printed in the log.  This should help mitigate the problems that arise when
   there's no more room left on the filesystem on which the server is dumping.

From pavel@arisia.Xerox.COM Fri Aug 23 12:35:43 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA01165; Fri, 23 Aug 91 12:35:42 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA03316; Fri, 23 Aug 91 12:29:46 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11754>; Fri, 23 Aug 1991 12:28:24 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 23 Aug 1991 12:28:17 -0700
Message-Id: <91Aug23.122817pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 23 Aug 1991 12:28:10 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: LambdaMOO Programmer's Manual, Version 1.4, Released!

Now available for anonymous FTP from host `parcftp.xerox.com', in directory
`pub/MOO', are the following files:

	ProgrammersManual.texinfo
	texinfo.tex
	ProgrammersManual.txt
	ProgrammersManual.ps
	ProgrammersManual.ps.Z

This version of the manual is intended to be complete and consistent with
release 1.4.0 of the LambdaMOO server.  I would appreciate hearing if this is
not the case...

	Pavel

From pavel@arisia.Xerox.COM Fri Aug 23 17:27:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA01686; Fri, 23 Aug 91 17:27:44 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01203; Fri, 23 Aug 91 17:19:59 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12072>; Fri, 23 Aug 1991 17:19:45 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 23 Aug 1991 17:19:35 -0700
Message-Id: <91Aug23.171935pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 23 Aug 1991 17:19:32 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: New LambdaCore released for use with server version 1.4.0

A new release of the LambdaCore database has been released and is available for
anonymous FTP from the host `parcftp.xerox.com' in the file
`pub/MOO/LambdaCore-22Aug91.db'.

	Pavel

From scott@suna0.cs.uiuc.edu Sun Aug 25 05:49:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <scott@suna0.cs.uiuc.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03032; Sun, 25 Aug 91 05:49:54 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA00025; Sun, 25 Aug 91 05:42:41 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11888>; Sun, 25 Aug 1991 05:42:26 PDT
Received: from sunc5.cs.uiuc.edu ([128.174.244.85]) by alpha.xerox.com with SMTP id <11888>; Sun, 25 Aug 1991 05:41:56 PDT
Received: by sunc5.cs.uiuc.edu id AA29832
  (5.65b/IDA-1.4.3 for MOO-Cows@Xerox.Com); Sun, 25 Aug 91 07:41:49 -0500
X-Ns-Transport-Id: 08002008D0FD000F93A4
Message-Id: <9108251241.AA29832@sunc5.cs.uiuc.edu>
Date: 	Sun, 25 Aug 1991 05:41:49 PDT
From: Jay Scott <scott@suna0.cs.uiuc.edu>
To: MOO-Cows.PARC@xerox.com
Subject: the lurking danger

Here's a pretend verb. The comment about permissions is accurate.
To the unaided eye, :zap looks unbreakable. But there is a subtle
flaw; there is a way that :zap can crash without anybody's making
an effort to crash it.

.program gizmotron:zap
  "'zap (<target object>)' - Zap a target with a ray gun.";
  "The target is always owned by gizmotron.owner, so there are";
  "no permission problems.";

  target = args [1];
  if (valid (target))
    target.location:announce_all
         (player.name, " zaps ", target.name, " with a ray gun!");
    target.name = "blackened " + target.name;
  endif
.

If you have an electron microscope, you can spot the tragic flaw.
During the call to :announce_all, everything in the room will get
a :tell. One of those :tell's may do a suspend() (I have seen one
:tell which does that). At the suspend(), other tasks may run. It
may be that one of those tasks is a player's command, which reads
'@recycle target'. Then when :zap runs again, 'target.name = ...'
will fail.

Nobody has done anything wrong here. :zap did check its argument,
and in the best of all possible worlds, it could rely on 'target'
to stay put. :announce_all can be expensive, so allowing it to do
an occasional suspend() is reasonable.

The problem is perfectly general; it is just the nature of multi-
tasking. What was the case before a suspend() may not be the case
afterward, and any old core verb can use suspend()--perhaps today
it doesn't, but tomorrow it might. And so the entire MOO falls in
a state of subtle tension, where somebody else's unrelated action
may just happen to break your verb, once, and you may never guess
why.

The only simple solution is to get rid of suspend(). But the uses
of suspend() are obvious and good, while the dangers are tiny and
rare. I don't know what to do about this dilemma. Putting up with
out-of-ticks errors is bad; putting up with occasional mysterious
verb crashes is bad; going to a more automatic time slice method,
the kind that operating systems use, would eliminate out-of-ticks
but cause more mystery crashes.

Help! What should we do?

As a first line of defense, I propose that the header comment for
each core verb that either does, or someday might, use suspend(),
should mention the fact.

I ought to point out that, as far as I know, this one microscopic
problem with suspend() has not actually caused any crashes. Maybe
we can just live with it.

	Frand
	scott@cs.uiuc.edu

From jashley@arisia.Xerox.COM Sun Aug 25 08:39:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <jashley@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03100; Sun, 25 Aug 91 08:39:28 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA02186; Sun, 25 Aug 91 08:35:01 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11889>; Sun, 25 Aug 1991 08:34:51 PDT
Received: from miles.parc.xerox.com ([13.2.17.18]) by alpha.xerox.com with SMTP id <11889>; Sun, 25 Aug 1991 08:34:39 PDT
Received: by miles.parc.xerox.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA17034; Sun, 25 Aug 91 08:32:49 PDT
X-Ns-Transport-Id: 08002008D0FD000F93D3
In-Reply-To: "Jay Scott's message of Sun, 25 Aug 1991 05:41:49 -0700 <9108251241.AA29832@sunc5.cs.uiuc.edu>"
Message-Id: <9108251532.AA17034@miles.parc.xerox.com>
Date: 	Sun, 25 Aug 1991 08:32:49 PDT
From: jashley@parc.xerox.com
To: MOO-Cows.PARC@xerox.com
Subject: the lurking danger


   The problem is perfectly general; it is just the nature of multi-
   tasking. What was the case before a suspend() may not be the case
   afterward.

Well, when it's *you* that does the suspend, you are braced for changes
in the world.  It's only when you call someone else's code that this
might turn around and bite you.

   Help! What should we do?

I've thought about this some before.  One solution that might work is to
add some syntax that looks like

      watch (id_1, ..., id_n)
        stmnt;
      endwatch

The identifiers must be all bound when the statement is executed.  An 
exception is raised if any of those bindings change or lose reference 
(e.g. the object they refer to is reycycled) when the statement is executed.

The language will obviously need a better exception handling facility to
support this, but since that's already on the list of things to do, I
don't mind making the assumption that it exists.


Mike

From sfwhite@watcgl.waterloo.edu Sun Aug 25 11:46:56 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03174; Sun, 25 Aug 91 11:46:55 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA04500; Sun, 25 Aug 91 11:41:11 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11889>; Sun, 25 Aug 1991 11:41:06 PDT
Received: from watcgl.waterloo.edu ([129.97.140.64]) by alpha.xerox.com with SMTP id <11889>; Sun, 25 Aug 1991 11:40:32 PDT
Received: by watcgl.waterloo.edu
	id <AA16958>; Sun, 25 Aug 91 14:40:23 -0400
X-Ns-Transport-Id: 08002008D0FD000F944E
Message-Id: <9108251840.AA16958@watcgl.waterloo.edu>
Date: 	Sun, 25 Aug 1991 11:40:23 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: MOO-Cows.PARC@xerox.com, scott@suna0.cs.uiuc.edu
Subject: Re:  the lurking danger

one possible solution to this problem (which becomes even more a
problem in COOLMUD, since every method (function) call may cause a
suspend()) is to force the server to treat certain blocks of code as
atomic.

for example, the location/contents manipulation (which is not
built-in in COOLMUD) must be atomic, or database corruption can occur
(conjuring up the race condition is left as an exercise to the
reader).

the idea i'm toying with in COOLMUD is a pair of functions, lock()
and unlock(), which simply lock the object in question from being
modified.  if another function attempts to modify the objects'
variables, recycle it, etc., the server would raise E_LOCKED.

if lock() is called and the object is already locked, the function
blocks until the object is unlocked.

comments?

-- stephen

From latour!mcr Sun Aug 25 13:10:36 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03212; Sun, 25 Aug 91 13:10:34 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA05563; Sun, 25 Aug 91 13:05:33 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11891>; Sun, 25 Aug 1991 13:05:29 PDT
Received: from bertrand.ccs.carleton.ca ([134.117.1.13]) by alpha.xerox.com with SMTP id <11891>; Sun, 25 Aug 1991 13:04:49 PDT
Received: from latour.UUCP by bertrand.ccs.carleton.ca (4.1/SMI-4.0)
	id AA18621; Sun, 25 Aug 91 16:03:16 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA22648; Sun, 25 Aug 91 15:31:40 EDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD000F9486
In-Reply-To: "Stephen White <sfwhite@watcgl.waterloo.edu>
       \"Re:  the lurking danger\" (Aug 25, 11:40am)te: Sun,"
Message-Id: <9108251931.AA22648@Sandelman.OCUnix.On.Ca>
Date: 	Sun, 25 Aug 1991 12:31:35 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: latour!mcr
To: Stephen White <sfwhite@watcgl.waterloo.edu>, MOO-Cows.PARC@xerox.com
Subject: Re:  the lurking danger

On Aug 25, 11:40am, Stephen White wrote:
} suspend()) is to force the server to treat certain blocks of code as
} atomic.

  It would be nice to have the ``compiler'' determine this itself (but just
issue warnings?). 

} the idea i'm toying with in COOLMUD is a pair of functions, lock()
} and unlock(), which simply lock the object in question from being
} modified.  if another function attempts to modify the objects'
} variables, recycle it, etc., the server would raise E_LOCKED.

  And what do you about deadlocks? You'll need
lock(var,var,var,var...)

} comments?

  I was pondering the problems of making a Moo/Mud work in a
distributed fashion (in a closely coupled machine/lan), probably with
the database itself being a seperate task, perhaps Ingres or Postgres. 
  It really comes down to the same problems, doesn't it?




-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!



From sfwhite@watcgl.waterloo.edu Sun Aug 25 16:37:31 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA03360; Sun, 25 Aug 91 16:37:29 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA08436; Sun, 25 Aug 91 16:33:09 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11895>; Sun, 25 Aug 1991 16:32:50 PDT
Received: from watcgl.waterloo.edu ([129.97.140.64]) by alpha.xerox.com with SMTP id <11895>; Sun, 25 Aug 1991 16:32:33 PDT
Received: by watcgl.waterloo.edu
	id <AA24833>; Sun, 25 Aug 91 19:32:29 -0400
X-Ns-Transport-Id: 08002008D0FD000F9534
Message-Id: <9108252332.AA24833@watcgl.waterloo.edu>
Date: 	Sun, 25 Aug 1991 16:32:29 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: MOO-Cows.PARC@xerox.com, mcr@sandelman.ocunix.on.ca,
        sfwhite@watcgl.waterloo.edu
Subject: Re:  the lurking danger

On Aug 25, 11:40am, Stephen White wrote:
>> suspend()) is to force the server to treat certain blocks of code as
>> atomic.

> It would be nice to have the ``compiler'' determine this itself (but just
> issue warnings?).   

i'm not sure how you'd do this, short of detecting any place where
object variables were assigned and locking between them.  is this
what you had in mind?

>> the idea i'm toying with in COOLMUD is a pair of functions, lock()
>> and unlock(), which simply lock the object in question from being
>> modified.  if another function attempts to modify the objects'
>> variables, recycle it, etc., the server would raise E_LOCKED.

> And what do you about deadlocks? You'll need
> lock(var,var,var,var...)

hmmm.  i'm new to the distributed database problem.  i don't *think*
it can deadlock, but i'm not positive.  perhaps you could give me an
example?  

> It really comes down to the same problems, doesn't it?

yeah.  distributed or multi-tasking, preventing your database from
becoming spam is No Fun.

-- stephen

From latour!mcr Mon Aug 26 11:10:26 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <latour!mcr>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05145; Mon, 26 Aug 91 11:10:20 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01116; Mon, 26 Aug 91 11:03:33 -0700
Received: from bertrand.ccs.carleton.ca ([134.117.1.13]) by alpha.xerox.com with SMTP id <11560>; Mon, 26 Aug 1991 11:03:15 PDT
Received: from latour.UUCP by bertrand.ccs.carleton.ca (4.1/SMI-4.0)
	id AA12645; Mon, 26 Aug 91 14:01:37 EDT
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA03441; Mon, 26 Aug 91 13:08:36 EDT
Message-Id: <9108261708.AA03441@Sandelman.OCUnix.On.Ca>
In-Reply-To: Stephen White <sfwhite@watcgl.uwaterloo.ca>
       "Re:  the lurking danger" (Aug 26, 11:50am)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Date: 	Mon, 26 Aug 1991 10:08:35 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
To: moo-cows@arisia.Xerox.COM
Subject: Re:  the lurking danger

On Aug 26, 11:50am, Stephen White wrote:
} basically, i was envisioning something even simpler than that.  the
} lock() primitive would lock _the entire object_ (all variables) from
} modification by other procedures until unlock()ed.  locking on a set
} of variables would be conceptually cleaner, however.

  What kind of permissions does one need to lock() part or all of an object?
Or does it simply require wizard permission, assuming that the only people
that should be worrying about multi-tasking on one object should be
the wizards??




-- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!



From pavel@arisia.Xerox.COM Mon Aug 26 11:15:35 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05175; Mon, 26 Aug 91 11:15:33 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01252; Mon, 26 Aug 91 11:09:19 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11560>; Mon, 26 Aug 1991 11:09:07 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 26 Aug 1991 11:08:57 -0700
Message-Id: <91Aug26.110857pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 26 Aug 1991 11:08:55 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Bugs in LambdaCore-22Aug91.db

A couple of easily-fixed bugs have been found in the LambdaCore-22Aug91.db
database.  If you've taken a copy of it, you should type the following two
commands, as Wizard:

	$hacker.password = $no_one.password
	$verb_editor.owner = $note_editor.owner = $mail_editor.owner = $hacker

Alternatively, you can get a copy of LambdaCore-26Aug91.db, which already has
these fixes applied.

	Pavel

From pavel@arisia.Xerox.COM Mon Aug 26 12:01:57 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA05361; Mon, 26 Aug 91 12:01:55 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA02505; Mon, 26 Aug 91 11:49:23 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11565>; Mon, 26 Aug 1991 11:49:10 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 26 Aug 1991 11:49:02 -0700
Message-Id: <91Aug26.114902pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 26 Aug 1991 11:48:51 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: One more bug in LambdaCore-22Aug91.db

[There were a couple of missing semicolons in my previous note, and I found one
 more little bug...]

There are a few easily-fixed bugs in the LambdaCore-22Aug91.db database.  If
you've already taken a copy of it, you should type the following commands as
Wizard:

	;$hacker.password = $no_one.password
	;$verb_editor.owner = $note_editor.owner = $mail_editor.owner = $hacker
	;$verb_editor.help = $note_editor.help = $editor_help
	;$generic_editor.help = $mail_editor.help = $editor_help

Alternatively, you can get a copy of LambdaCore-26Aug91.db, which already has
these fixes applied.

	Pavel

From pavel@arisia.Xerox.COM Wed Sep  4 09:01:15 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA00462; Wed, 4 Sep 91 09:01:12 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA24224; Wed, 4 Sep 91 08:54:12 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11779>; Wed, 4 Sep 1991 08:53:52 PDT
Received: by lambda.parc.xerox.com id <58369>; Wed, 4 Sep 1991 08:53:42 -0700
Fake-Sender: pavel@parc.xerox.com
Message-Id: <91Sep4.085342pdt.58369@lambda.parc.xerox.com>
Date: 	Wed, 4 Sep 1991 08:53:38 PDT
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re:  the lurking danger

This message was originally sent to
	MOO-Cows@lambda.parc.xerox.com
which failed.  The proper address for submissions to MOO-Cows is
	MOO-Cows@Xerox.Com

------- Start of forwarded message -------
From: mcr@Sandelman.OCUnix.On.Ca (Michael Richardson)
Date: Mon, 26 Aug 1991 01:58:53 -0400
In-Reply-To: Stephen White <sfwhite@watcgl.uwaterloo.ca>
       "Re:  the lurking danger" (Aug 25,  7:32pm)
To: Stephen White <sfwhite@watcgl.uwaterloo.ca>,
        moo-cows@lambda.parc.xerox.com
Subject: Re:  the lurking danger

  [Did you CC back to Moo-cows?]
On Aug 25,  7:32pm, Stephen White wrote:
} > It would be nice to have the ``compiler'' determine this itself (but just
} > issue warnings?).   
} 
} i'm not sure how you'd do this, short of detecting any place where
} object variables were assigned and locking between them.  is this
} what you had in mind?

  Yes, also looking for places where variables that are assigned are
computed from other (changeable) variables/properties. This would
catch 
  obj.count=dobj.count+1;

  as well as
  obj.count++;

} > And what do you about deadlocks? You'll need
} > lock(var,var,var,var...)
} 
} hmmm.  i'm new to the distributed database problem.  i don't *think*
} it can deadlock, but i'm not positive.  perhaps you could give me an
} example?  

  Process A:
  lock(varA);
  (do lengthy computation involving A)
  lock(varB);
  varB = varA + varB
  unlock(varA);
  unlock(varB);

  Process B:
  lock(varB);
  (do lengthy computation involving B)
  lock(varA);
  varA = varA + varB
  unlock()...

  Time sequence:

  A                         B
  lock(varA);
  ...compute...             lock(varB);
  ...compute...
  lock(varB); /* block */   ...compute...
                            lock(varA); /* block */

  This is a simple (contrived) example. A MOO has many programmers,
and would be very difficult to coordinate.
  The solution to the above is to make sure you have all the resources
you need at the beginning, or you take none and wait. 
  lock(varA,varB);  would not lock either until both can be locked.

} > It really comes down to the same problems, doesn't it?
} 
} yeah.  distributed or multi-tasking, preventing your database from
} becoming spam is No Fun.

  In the Self group, they are talking about things like having a
simple (stupid) compiler as the interactive one, and launching a
background sophisticated compiler that would run at a lower priority.
Thus good code, but strong interaction. I would imagine that the
simple code could profile itself easily, so discovering which data
need not be protected could also be done via observation. 
  At some point I guess the OODB, the internal database (e.g.
Mud/Moos), and the pure OOP people will converge to some common
ground. 


- -- 
   :!mcr!:            |  The postmaster never | So much mail, 
   Michael Richardson |    resolves twice.    |  so little time.
HOME: mcr@sandelman.ocunix.on.ca 	Bell: (613) 237-5629
    Small Ottawa nodes contact me about joining ocunix.on.ca!


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

From dxb105@phyvs1.anu.edu.au Fri Sep 13 01:24:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dxb105@phyvs1.anu.edu.au>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA07517; Fri, 13 Sep 91 01:24:27 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA26305; Fri, 13 Sep 91 00:48:01 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11525>; Fri, 13 Sep 1991 00:47:44 PDT
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <11525>; Fri, 13 Sep 1991 00:46:55 PDT
Received: by phys.anu.edu.au (MX V2.3) id 31953; Fri, 13 Sep 1991 17:49:34 EDT
X-Ns-Transport-Id: 08002008D0FD00106F6A
Message-Id: <0094E97A.B2E96820.31953@phys.anu.edu.au>
Date: 	Fri, 13 Sep 1991 14:49:34 PDT
From: David Bofinger <dxb105@phyvs1.anu.edu.au>
To: MOO-Cows.parc@xerox.com
Cc: dxb105@phyvs1.anu.edu.au
Subject: Suspending Verbs

I tried sending this before. What's the correct address for MOO-Cows, someone?

I think we need a bit on verbs that states whether they can be suspended. The
motive is to stop people murdering tasks by suspend(maxint)ing them. The idea
is this:

When MOO hits a suspend() primitive, it looks back through callers() for a verb
that cannot be suspended. A verb can be suspended by anyone if it has the s bit
set, or can be suspended by a wizard or its owner. If it doesn't find one,
suspend() works normally. If it does, suspend() queues one task and continues
with another.

The queued task is what would normally be run, except that callers() gets
truncated, control is not be returned to the verb that refused to be
suspended.

The immediately continuing task starts in the verb that refused to be
suspended, just after the verb that got called (if it was in an expression,
it's return value is something distinctive, perhaps an error value). 

One could argue that the d bit should work this way too. i.e. A !d verb should
not crash because one of the verbs it called crashed. Instead, the verb highest
on the stack that feels confident to continue should be invited to do so.

Most verbs would probably be !s. Especially, $room:announce*_all_but() would
be. It's an interesting thought that suspend()'s permissions are rather
UberMUD-like, i.e. Let the caller beware.
------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
		MOO:	Marion, who wants to know why people regard her as
			having less independent existence than Black_Norway.
                Snail:	Dept. of Theoretical Physics, RSPhysS, ANU, ACT, 2601
------------------------------------------------------------------------------

From pavel@arisia.Xerox.COM Fri Sep 13 09:10:55 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA08158; Fri, 13 Sep 91 09:10:54 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA20441; Fri, 13 Sep 91 09:04:11 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11613>; Fri, 13 Sep 1991 09:03:56 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 13 Sep 1991 09:03:47 -0700
In-Reply-To: <0094E97A.B2E96820.31953@phys.anu.edu.au>
Message-Id: <91Sep13.090347pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 13 Sep 1991 09:03:46 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows@arisia.Xerox.COM
Subject: Re: Correct address for MOO-Cows

David Bofinger writes:
> I tried sending this before. What's the correct address for MOO-Cows?

The correct address for submissions is `MOO-Cows@Xerox.Com', regardless of what
might be given as the return address in any particular submission.

The correct address for administrative matters (e.g., adding or deleting
members from the list, fixing address problems, etc.) is
`MOO-Cows-Request@Xerox.Com'.

	Pavel

From pavel@arisia.Xerox.COM Fri Sep 13 09:31:56 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@arisia.Xerox.COM>
Received: from arisia.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AA08218; Fri, 13 Sep 91 09:31:54 PDT
Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA20930; Fri, 13 Sep 91 09:25:28 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11728>; Fri, 13 Sep 1991 09:25:18 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 13 Sep 1991 09:25:07 -0700
In-Reply-To: <0094E97A.B2E96820.31953@phys.anu.edu.au>
Message-Id: <91Sep13.092507pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 13 Sep 1991 09:25:06 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: dxb105@phyvs1.anu.edu.au
Cc: moo-cows@arisia.Xerox.COM
Subject: Re: Suspending Verbs

As with the `d' bit on verbs, I think that verb-wide coverage is too large a
scope for this kind of control; it's just too clumsy.  Instead, I think a
language construct with a limited scope would be more appropriate and easier to
use.

For example, I have been considering for some time adding the statement

	RAISE expression;

and the expression

	` expression '

to the language to allow MOO programs to raise and handle errors.  The idea is
that the RAISE statement is kind of like RETURN except that the value of the
given expression is raised as an error, not simply returned to the verb's
caller.  The quoted expression shown above would server for catching errors
raised either by the RAISE statement or by primitive functions and other
constructs of the language (e.g., type errors, division by zero, etc.).  The
idea is that the expression

	` e '

evaluates e as usual and, if no error is raised during that evaluation, simply
returns the resulting value.  If, however, evaluation of e causes an error to
be raised, that error value would immediately be returned from the quoted
expression and execution would continue as before.

Thus, for example, one could safely say

	if (typeof(`z:foo()') == ERR)
	  ... recover from the error ...
	endif

assuming that z:foo() never returns an error value.  If you had no guarantee as
to what kind of value it might return, you could still detect whether or not an
error had occurred as follows:

	x = 1; y = 0;
	x = `y = z:foo()';
	if (x != y)
	  ... recover from the error ...
	endif

This sort of dancing should rarely be necessary, however.

In any case, I think that this sort of more local control over error-handling
or any other such matter, including supression of suspending, is a better
approach than verb-wide scoping.

Regardless of the mechanism, though, David's particular semantics for
suspend-suppression is very interesting to me.  The idea of having both the
suspender and the suppressor `get their wishes' had never occurred to me.  It's
worth thinking about.

I feel obliged to point out, however, that none of these changes to the MOO
language will be implemented (at least by me) before next January at the
earliest.  I am quite busy with other projects and will be at least through the
end of the year.  I will try to respond quickly to bug reports on the server in
the meantime, though, and there may be one or more minor server releases to
make such bug fixes widely available.

Do keep the MOO-Cows mail flowing, though.  If we build up an exciting list of
ideas for improvement of the language or the server, it can only increase the
chances of my getting back to server-hacking sooner rather than later.

	Pavel

From pavel@parc.xerox.com Fri Sep 20 11:38:44 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA23714; Fri, 20 Sep 91 11:38:43 PDT
Received: from Maverick.Parc.Xerox.xns by alpha.xerox.com via XNS id <12319>; Fri, 20 Sep 1991 11:21:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12817>; Fri, 20 Sep 1991 10:31:40 PDT
Received: by lambda.parc.xerox.com id <58369>; Fri, 20 Sep 1991 10:28:08 -0700
X-Ns-Transport-Id: 08002008D0FD0010C67C
Message-Id: <91Sep20.102808pdt.58369@lambda.parc.xerox.com>
Date: 	Fri, 20 Sep 1991 10:28:02 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: New LambdaMOO server release, version 1.4.5

I've made a `patch' release of the version 1.4 LambdaMOO server; this release
is numbered 1.4.5.  I made it to fix a potentially nasty bug in the code that
figures out what line number to print in error tracebacks, but a number of
other changes have accumulated as well.  None of these changes should be
particularly user-visible except as bug fixes.  I've appended the change-log to
the end of this message.

The new server can be copied from host `parcftp.xerox.com', directory
`pub/MOO', as `LambdaMOO-1.4.5.tar.Z'.  Don't forget to use `binary' mode in
FTP...

	Pavel/Haakon/Lambda

>From ChangeLog.txt:

Version 1.4.5, 20 September 1991
-- Made unparser failures panic the server rather than try to press on.
-- Changed the task scheduler in two important ways:
	1) Effectively gave each player's input tasks a higher priority than
	   their forked or suspended tasks.  This should both improve
	   interactive response and make it possible for users to recover from
	   accidentally forking off many tasks; they can now run commands to
	   kill those tasks and avoid having those commands wait behind all of
	   the forked tasks.
	2) The scheduler no longer uses a strictly round-robin algorithm for
	   choosing which player's task to run next.  Instead, it keeps track
	   of how many seconds have been consumed by each player's tasks and
	   runs the next task from the queue with the least total `usage'.
	   Fresh queues and those queues that are empty when it becomes their
	   turn to run again are kept apart from non-empty queues.  When an
	   empty queue next gets a task to run, its usage is set equal to the
	   least usage of already-non-empty queues.  Thus, such queues go to
	   the head of the list but have no advantage over the queues that were
	   never empty.  This more complex scheduling scheme is intended to
	   ameliorate the problems with some players having long-running tasks
	   constantly runnable in the background; such players will now get
	   only their fair share of the server.
-- Fixed queued_tasks() to list the player being read from as the owner of a
   reading task.  This makes it consistent with kill_task(), which only allows
   that player to kill such a task.
-- Fixed a bug with my use of signal() on some POSIX-compliant machines.  One
   possible consequence of the bug (actually manifest on the IRIS) is that all
   checkpointing processes after the first one will never be waited for,
   leaving `defunct' processes lying around until the server itself terminates.
-- Fixed a small bug in my use of ANSI C: the `typedef enum Opcode Opcode;'
   line in opcode.h must come *after* the definition of `enum Opcode'; unlike
   struct types, enum types may not be forwardly referenced.  Thanks to yduJ
   and the Lucid C compiler for finding this bug.
-- Fixed a bug in the line-number-finding code; this bug was identical to one
   we fixed long ago in the unparser.  Since the LNF code is *derived* from the
   unparsing code, this is unsurprising.  What's embarassing is that we forgot
   to fix the LNF code at the same time...

From STJS@vm.marist.edu Fri Sep 20 11:57:04 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <STJS@vm.marist.edu>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB23809; Fri, 20 Sep 91 11:57:03 PDT
Received: from Maverick.Parc.Xerox.xns by alpha.xerox.com via XNS id <11708>; Fri, 20 Sep 1991 11:46:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11734>; Fri, 20 Sep 1991 11:38:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 20 Sep 1991 11:36:06 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11804>; Fri, 20 Sep 1991 11:12:35 PDT
Received: from VM.MARIST.EDU ([148.100.1.2]) by alpha.xerox.com with SMTP id <12563>; Fri, 20 Sep 1991 10:04:44 PDT
Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R1)
   with BSMTP id 1438; Fri, 20 Sep 91 13:05:03 EDT
Received: by MARIST (Mailer R2.07) id 9261; Fri, 20 Sep 91 13:05:03 EDT
X-Ns-Transport-Id: 08002008D0FD0010C61D
Message-Id: <91Sep20.100444pdt.12563@alpha.xerox.com>
Date: 	Fri, 20 Sep 1991 09:54:47 PDT
From: "Joey J. Stanford FF-EMT-EMD (RESCUE-1)" <STJS@vm.marist.edu>
To: MOO-COWS.PARC@xerox.com
Subject: Question....



 Gang,

 I'm having an interesting time trying to design a verb to do what I want.
Anyone have any ideas...:

 Here's some background....

  I have a combo sprinkler/fire alarm/actuator.  I have the designs more or
less done for the sprinkler and fire alarm functions.  The actuator is what
I'm having trouble on.  The desired effect is this:

 When an alarm is pulled somewhere in the mansion, all the other actuators
will go off with a message saying "player' has activated the fire
alarm in where'"

   The effect is that they are all interconnected.  I look at the
Generic Radio a little but could still come up with one idea that I find
unacceptable.
   My only idea is to have each sprinkler fork a job that checks somewhere to
see if there are any activations, then suspends...and reactivates...continually
....my problem is that this really hogs cpu time.  I'd like to find a way to
have one sprinkler be able to run an actuator verb on anything with a parent
class of sprinkler or some such thing.  The key is ...withOUT having a list
off all the sprinklers...just saying 'issue this_msg to all parents(#xxxx)'


 Can it be done?  any ideas?


 Thanks...

 jj

From STJS@vm.marist.edu Fri Sep 20 12:24:37 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <STJS@vm.marist.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA23922; Fri, 20 Sep 91 12:24:36 PDT
Received: from Charon.Parc.Xerox.xns by alpha.xerox.com via XNS id <11716>; Fri, 20 Sep 1991 12:15:11 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11782>; Fri, 20 Sep 1991 11:40:07 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Fri, 20 Sep 1991 11:38:36 -0700
Received: from Charon.Parc.Xerox.xns by alpha.xerox.com via XNS id <11808>; Fri, 20 Sep 1991 11:12:55 PDT
Received: from VM.MARIST.EDU ([148.100.1.2]) by alpha.xerox.com with SMTP id <12597>; Fri, 20 Sep 1991 10:08:45 PDT
Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R1)
   with BSMTP id 1440; Fri, 20 Sep 91 13:09:05 EDT
Received: by MARIST (Mailer R2.07) id 9282; Fri, 20 Sep 91 13:09:05 EDT
X-Ns-Transport-Id: 08002008D0FD0010C629
Message-Id: <91Sep20.100845pdt.12597@alpha.xerox.com>
Date: 	Fri, 20 Sep 1991 10:07:06 PDT
From: "Joey J. Stanford FF-EMT-EMD (RESCUE-1)" <STJS@vm.marist.edu>
To: "An Utter MOO of a good time...." <MOO-COWS@xerox.com>
Subject: @Peditor help


 Here's another question from the "newbie"....


Is there anyway to edit the description property

(ex   @pedit me.description)

and have it come out WYSIWYG instead of run together as I seem to be
getting it now?

Thanks,

 jj

From parc.xerox.com.PARC@xerox.com Fri Sep 20 12:41:24 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com.PARC@xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA24025; Fri, 20 Sep 91 12:41:24 PDT
Errors-To: parc.xerox.com.PARC@xerox.com
Received: from Storm.Parc.Xerox.xns by alpha.xerox.com via XNS id <11666>; Fri, 20 Sep 1991 12:40:21 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11588>; Fri, 20 Sep 1991 12:38:33 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 20 Sep 1991 12:37:29 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11682>; Fri, 20 Sep 1991 12:35:15 PDT
Received: from po5.andrew.cmu.edu ([128.2.10.105]) by alpha.xerox.com with SMTP id <14097>; Fri, 20 Sep 1991 09:03:00 PDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA01808> for moo-cows@xerox.com; Fri, 20 Sep 91 09:40:09 EDT
Received: via switchmail; Fri, 20 Sep 1991 09:40:07 -0400 (EDT)
Received: from ccon.bh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.ocqTbz:00VAtA0WUsa>;
          Fri, 20 Sep 1991 09:39:11 -0400 (EDT)
Received: from ccon.bh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr24/jb7w/.Outgoing/QF.gcqTbpm00VAtQWl:UD>;
          Fri, 20 Sep 1991 09:39:02 -0400 (EDT)
Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.ccon.bh.andrew.cmu.edu.pmax.ul4
          via MS.5.6.ccon.bh.andrew.cmu.edu.pmax_ul4;
          Fri, 20 Sep 1991 09:39:01 -0400 (EDT)
X-Ns-Transport-Id: 08002008D0FD0010C4F6
Xns-Originator: parc.xerox.com.PARC@Xerox.com
Errors-To: parc.xerox.com.PARC@xerox.com
Message-Id: <McqTbpe00VAt8Wl_Nj@andrew.cmu.edu>
Date: 	Fri, 20 Sep 1991 06:39:01 PDT
From: Joseph Gerard Behrmann <jb7w+@andrew.cmu.edu>
Sender: <@po5.andrew.cmu.edu:jb7w+@andrew.cmu.EDU>
To: moo-cows.PARC@xerox.com
Subject: What is the $hacker in the new Core Database?

Does the player #4 (or $hacker) do anything useful in the new databse,
what is its purpose?  And what about Everyman (#13)?  I just
downloaded the core to peek at it and found this, I dislike going
through all of the code to find out what it does, could anyone just
tell me?


EVERYTHING NOT FORBIDDEN IS COMPULSORY - A little ant
"All that we see or seem is but a dream within a dream." - E.A.P.
						Joe
						jb7w+@andrew.cmu.edu

From yduj@lucid.com Fri Sep 20 13:44:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA24250; Fri, 20 Sep 91 13:44:44 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11652>; Fri, 20 Sep 1991 13:43:57 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11538>; Fri, 20 Sep 1991 13:40:47 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 20 Sep 1991 13:39:32 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11565>; Fri, 20 Sep 1991 13:39:12 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11589>; Fri, 20 Sep 1991 13:38:14 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA27129g; Fri, 20 Sep 91 13:32:45 PDT
Received: by boston-harbor id AA07161g; Fri, 20 Sep 91 16:38:52 EDT
X-Ns-Transport-Id: 08002008D0FD0010C9C3
In-Reply-To: "\"Joey J. Stanford FF-EMT-EMD (RESCUE-1)\"'s message of Fri, 20 Sep 1991 09:54:47 PDT <91Sep20.100444pdt.12563@alpha.xerox.com>r"
Message-Id: <9109202038.AA07161@boston-harbor>
Date: 	Fri, 20 Sep 1991 13:38:52 PDT
From: Judy Anderson <yduj@lucid.com>
To: STJS@vm.marist.edu
Cc: MOO-COWS.PARC@xerox.com
Subject: Question....

I'm confused about what you are actually trying to do, but I
frequently have the parent object of a class act a little differently
than its children.  For example, the master bedroom puzzle has three
rooms in which the alarm sounds.  I have this.rootobj = #5992, the
parent, in all three children and the parent.  I forget the numbers of
the children...  But when the alarm is tripped, it just does something
along the lines of

for room in (children(this.rootobj)) 
   room:announce(room.beem_msg);
endfor

I could just as easily done

for room in (children(parent(this)))
 etc.

I chose not to, because of the way I arranged my internal verbs;
sometimes "this" ends up being set to the parent object rather than
one of the children, and then that idiom would get me all the children
of $room, not at all what I had in mind.  If you know that "this" will
always be one of the children, then you can save the "rootobj" property.

Re your @pedit me.description question...  The MOO always prints
strings on one line.  Your client does any line breaking.  Note that
other people's clients also do line breaking, perhaps following a
different algorithm, so if you want linebreaks to appear, don't put
them in with extra spaces, put them in by making a list of strings
instead.

yduJ on LambdaMOO        yduJ@lucid.com      'yduJ' rhymes with 'fudge'


From yduj@lucid.com Fri Sep 20 13:56:08 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA24290; Fri, 20 Sep 91 13:56:08 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11675>; Fri, 20 Sep 1991 13:55:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11652>; Fri, 20 Sep 1991 13:50:48 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 20 Sep 1991 13:48:59 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11535>; Fri, 20 Sep 1991 13:48:42 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11589>; Fri, 20 Sep 1991 13:47:02 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA27165g; Fri, 20 Sep 91 13:41:35 PDT
Received: by boston-harbor id AA07200g; Fri, 20 Sep 91 16:47:41 EDT
X-Ns-Transport-Id: 08002008D0FD0010C9EF
In-Reply-To: "Joseph Gerard Behrmann's message of Fri, 20 Sep 1991 06:39:01 PDT <McqTbpe00VAt8Wl_Nj@andrew.cmu.edu>"
Message-Id: <9109202047.AA07200@boston-harbor>
Date: 	Fri, 20 Sep 1991 13:47:41 PDT
From: Judy Anderson <yduj@lucid.com>
To: jb7w+@andrew.cmu.edu
Cc: moo-cows.PARC@xerox.com
Subject: What is the $hacker in the new Core Database?

$hacker owns a bunch of verbs and properties in the editor and mail
room which shouldn't have wiz perms.  Everyman ($noone)'s purpose is
to own *nothing*, and thus be a nice safe place to do possibly unsafe
evals.

set_task_perms($noone)
eval(user_code_string);

Thus we are protected against user_code_string being "player.wizard =
1" or "recycle(myfavoriteobject)", yet we can still get the features
of allowing people to evaluate code in various ways.  I don't know if
this is actually used anywhere; it was proposed for
$string_utils:pronoun_sub to be able to call verbs inside the string
iwth %{} or something.  It looks like that particular use was not
implemented, but there may be others.  (I'm too lazy to grep the DB.)

yduJ on LambdaMOO        yduJ@lucid.com      'yduJ' rhymes with 'fudge'


From crew@neon.stanford.edu Fri Sep 20 16:14:20 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA24723; Fri, 20 Sep 91 16:14:18 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11765>; Fri, 20 Sep 1991 16:13:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11760>; Fri, 20 Sep 1991 16:12:07 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 20 Sep 1991 16:10:52 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11760>; Fri, 20 Sep 1991 16:10:43 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11765>; Fri, 20 Sep 1991 16:09:50 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA17418; Fri, 20 Sep 91 16:09:47 -0700
X-Date: Fri, 20 Sep 91 15:26:24 PST
X-Ns-Transport-Id: 08002008D0FD0010CC39
In-Reply-To: "Your message of Fri, 20 Sep 91 13:47:41 -0700.
             <9109202047.AA07200@boston-harbor>"
Message-Id: <9109202309.AA17418@Neon.Stanford.EDU>
Date: 	Fri, 20 Sep 1991 16:09:45 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows.PARC@xerox.com
Subject: Re: What is the $hacker in the new Core Database?

>   $hacker owns a bunch of verbs and properties in the editor and mail
>   room which shouldn't have wiz perms.  

the general philosphy is that every wizard-owned verb (in particular,
every wizard-owned verb that doesn't start out set_task_perms(player)
or set_task_perms(caller_perms())) is a potential security hole, 
much like setuid-root executables in UNIX.

The alternative is going through all of the editor/mail-room verbs and
verifying by hand that there's no way anyone could use them to do anything
nonkosher, but this is silly --- one of the reasons for having permissions
in the first place is so that one doesn't have to do things like that.

>   Everyman ($no_one)'s purpose is
>   to own *nothing*, and thus be a nice safe place to do possibly unsafe
>   evals.
>   
>   set_task_perms($no_one)
>   eval(user_code_string);
   
This (modulo minor frills) is in fact the entire content of the verb 
$no_one:eval(string), which is intended for general consumption.

>   ...it was proposed for $string_utils:pronoun_sub to be able to
>   call verbs inside the string iwth %{} or something.  

not so much calling verbs (which already have a specified owner), 
as evaluating arbitrary expressions where it's not clear whose
permissions should be used.  Consider the typical use of
pronoun_sub()ing a _msg property.  Should the permissions used be
those of the owner of the property? the owner of the verb that's
calling :pronoun_sub? 

>   It looks like that particular use was not implemented, 
>   but there may be others.

Waitaminnit, it *is* used in pronoun_sub() to keep people from doing
things liked $string_utils:pronoun_sub("%n's password is %(password)"),
or at least it's supposed to be (...oh shit, somebody took it out...
...there, it's back... thanks for catching this, yduJ).

The other main use in the core-db at the moment is evaluating 
user-supplied expressions in the middle of $help texts 
(as in "this message defaults to x" or "here's what'll happen if *you* were 
to do x..."; look at `help whereis' or `help.thing-messages').

	Roger
--
Roger Crew
Internet:  crew@CS.Stanford.EDU      
MUD:       Rog    (okay, so I'm not into role-playing... sue me.)

From crew@neon.stanford.edu Fri Sep 20 16:24:37 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA24747; Fri, 20 Sep 91 16:24:36 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11754>; Fri, 20 Sep 1991 16:24:09 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11760>; Fri, 20 Sep 1991 16:22:38 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 20 Sep 1991 16:21:56 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11761>; Fri, 20 Sep 1991 16:21:28 PDT
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11754>; Fri, 20 Sep 1991 16:20:58 PDT
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA20369; Fri, 20 Sep 91 16:20:56 -0700
X-Ns-Transport-Id: 08002008D0FD0010CC5A
In-Reply-To: "Your message of Fri, 20 Sep 91 10:07:06 -0700.
             <91Sep20.100845pdt.12597@alpha.xerox.com>"
Message-Id: <9109202320.AA20369@Neon.Stanford.EDU>
Date: 	Fri, 20 Sep 1991 16:20:54 PDT
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows.PARC@xerox.com
Subject: Re: @Peditor help

>   Is there anyway to edit the description property
>   
>   (ex   @pedit me.description)
>   
>   and have it come out WYSIWYG instead of run together as I seem to be
>   getting it now?
  
Try @notedit me.decription

@notedit is recommended for anything that is a list-of-strings property.
#5803:@pedit is an experimental editor for all other kinds of properties.  

	Roger
--
Roger Crew
Internet:  crew@CS.Stanford.EDU
MUD:       Rog    (okay, so I'm not into role-playing... sue me.)

From parc.xerox.com.PARC@xerox.com Wed Sep 25 00:31:07 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com.PARC@xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA03529; Wed, 25 Sep 91 00:31:06 PDT
Errors-To: parc.xerox.com.PARC@xerox.com
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11696>; Wed, 25 Sep 1991 00:30:11 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11715>; Wed, 25 Sep 1991 00:26:37 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Wed, 25 Sep 1991 00:22:53 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11696>; Wed, 25 Sep 1991 00:22:11 PDT
Received: from po5.andrew.cmu.edu ([128.2.10.105]) by alpha.xerox.com with SMTP id <11711>; Wed, 25 Sep 1991 00:21:38 PDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA13130> for moo-cows@xerox.com; Wed, 25 Sep 91 03:21:32 EDT
Received: via switchmail; Wed, 25 Sep 1991 03:21:31 -0400 (EDT)
Received: from ccon.bh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.Ics3XnW00VAt40WW0B>;
          Wed, 25 Sep 1991 03:21:23 -0400 (EDT)
Received: from ccon.bh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr24/jb7w/.Outgoing/QF.Ecs3XVS00VAt4b904I>;
          Wed, 25 Sep 1991 03:21:05 -0400 (EDT)
X-Ns-Transport-Id: 08002008D0FD0010F637
Xns-Originator: parc.xerox.com.PARC@Xerox.com
Errors-To: parc.xerox.com.PARC@xerox.com
Message-Id: <Added.scs3Xw600Udd8nGE4P@andrew.cmu.edu>
Date: 	Wed, 25 Sep 1991 00:21:03 PDT
From: Joseph Gerard Behrmann <jb7w+@andrew.cmu.edu>
Sender: <@po5.andrew.cmu.edu:jb7w+@andrew.cmu.EDU>
To: moo-cows.PARC@xerox.com
Subject: Odd occurance...


	When I log into Lambda, I get the $welcome_message twice, does everybody
else get that too? I also have the same problem with my test MOO, I got the newqserver sources and compiled them, ran the server, and no problem, until I it hit
an error traceback in a verb I called.  Then the server hung, well I killed the
server and started with my save of the db from about 20 minutes before and the
multiple $welcome_messages showed up when I logged on.  It had not done that
before.  Anyone have any clues about this?  I was wondering if it might be a
symptom of db corruption or something...

						Joe

From pavel@parc.xerox.com Wed Sep 25 10:19:04 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA04432; Wed, 25 Sep 91 10:19:03 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11840>; Wed, 25 Sep 1991 10:17:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11834>; Wed, 25 Sep 1991 10:13:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Wed, 25 Sep 1991 10:08:49 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11827>; Wed, 25 Sep 1991 10:08:18 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11824>; Wed, 25 Sep 1991 10:07:23 PDT
Received: by lambda.parc.xerox.com id <58370>; Wed, 25 Sep 1991 10:07:16 -0700
X-Ns-Transport-Id: 08002008D0FD0010FABF
In-Reply-To: <Added.scs3Xw600Udd8nGE4P@andrew.cmu.edu>
Message-Id: <91Sep25.100716pdt.58370@lambda.parc.xerox.com>
Date: 	Wed, 25 Sep 1991 10:07:12 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: moo-cows.PARC@xerox.com
Subject: Re: Odd occurance...

Joseph Gerard Behrmann writes:
> When I log into Lambda, I get the $welcome_message twice, does everybody else
> get that too?

I have heard of this before and it has always been tracked to a MUD client that
sends a line of input upon connection.  The default implementation of
#0:do_login_command prints the $welcome_message if (a) the input is a null
line, (b) the command is `help', or (c) the command is unrecognized.  Check to
see if your client is sending such a line upon connection.  The server itself
artificially generates a null line of input for each new connection, just to
give #0:do_login_command an opportunity to print such a message.  If your
client was also sending a blank line on connection, that would explain the
double printing.

> I also have the same problem with my test MOO, I got the newqserver sources
> and compiled them, ran the server, and no problem, until I it hit an error
> traceback in a verb I called.  Then the server hung ...

I'm more interested in this problem than the other.  Are you running 1.4.5?
Is the hang reproducible?

> ... started with my save of the db from about 20 minutes before and the
> multiple $welcome_messages showed up when I logged on.  It had not done that
> before.  Anyone have any clues about this?  I was wondering if it might be a
> symptom of db corruption or something...

I doubt that any random kind of DB corruption could cause this; it would have
to change the code for #0:do_login_command in a way that was syntactically
correct and had this odd behavior.

	Pavel

From yduj@lucid.com Wed Sep 25 10:20:11 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA04437; Wed, 25 Sep 91 10:20:10 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11798>; Wed, 25 Sep 1991 10:18:48 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11851>; Wed, 25 Sep 1991 10:15:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 25 Sep 1991 10:13:55 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11798>; Wed, 25 Sep 1991 10:10:43 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11817>; Wed, 25 Sep 1991 10:10:17 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA13829g; Wed, 25 Sep 91 10:04:42 PDT
Received: by boston-harbor id AA22806g; Wed, 25 Sep 91 13:10:57 EDT
X-Ns-Transport-Id: 08002008D0FD0010FACD
In-Reply-To: "Joseph Gerard Behrmann's message of Wed, 25 Sep 1991 00:21:03 PDT <Added.scs3Xw600Udd8nGE4P@andrew.cmu.edu>"
Message-Id: <9109251710.AA22806@boston-harbor>
Date: 	Wed, 25 Sep 1991 10:10:57 PDT
From: Judy Anderson <yduj@lucid.com>
To: jb7w+@andrew.cmu.edu
Cc: moo-cows.PARC@xerox.com
Subject: Odd occurance...

When read() was added, the code that completely ignores blank lines
was removed from the server.  Probably your client is sending a blank
line at the start of the connection, producing a second banner
message.

Dunno about your other problems though.

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'

From seth@alchemy.tn.cornell.edu Wed Sep 25 10:39:05 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <seth@alchemy.tn.cornell.edu>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB04534; Wed, 25 Sep 91 10:39:04 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11807>; Wed, 25 Sep 1991 10:38:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11739>; Wed, 25 Sep 1991 10:35:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Wed, 25 Sep 1991 10:33:50 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11794>; Wed, 25 Sep 1991 10:33:20 PDT
Received: from alchemy.tn.cornell.edu ([128.84.253.9]) by alpha.xerox.com with SMTP id <11691>; Wed, 25 Sep 1991 10:32:37 PDT
Received: by alchemy.tn.cornell.edu (4.1/SMI-4.1)
	id AA06315; Wed, 25 Sep 91 13:33:58 EDT
X-Ns-Transport-Id: 08002008D0FD0010FB2D
Message-Id: <9109251733.AA06315@alchemy.tn.cornell.edu>
Date: 	Wed, 25 Sep 1991 10:33:58 PDT
From: seth@alchemy.tn.cornell.edu (Seth Cohn)
To: moo-cows.PARC@xerox.com
Subject: Moo Bots?


anyone made a MOO robot intelligence?
I'm aware of the various pets around, but was thinking
more along the lines of Julia from more traditional MUDs

Seth

From tellab5!odgate!dbk@uunet.uu.net Wed Sep 25 11:06:29 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <tellab5!odgate!dbk@uunet.uu.net>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB04619; Wed, 25 Sep 91 11:06:28 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11813>; Wed, 25 Sep 1991 11:05:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11783>; Wed, 25 Sep 1991 11:02:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Wed, 25 Sep 1991 11:00:56 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11789>; Wed, 25 Sep 1991 11:00:14 PDT
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11789>; Wed, 25 Sep 1991 10:59:42 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA15407; Wed, 25 Sep 91 13:59:45 -0400
Received: from tellab5.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 135815.4003; Wed, 25 Sep 1991 13:58:15 EDT
Received: by tellab5.CHI.IL.US (smail2.5)
	id AA15003; 25 Sep 91 10:47:59 CDT (Wed)
X-Ns-Transport-Id: 08002008D0FD0010FBAA
Message-Id: <9109251527.AA17533@odgate.odesta.com>
Date: 	Wed, 25 Sep 1991 08:27:00 PDT
From: odgate!dbk@uunet.uu.net (Dan Keith)
Sender: tellab5!odgate!dbk@uunet.uu.net
To: moo-cows.parc@xerox.com
Cc: dbk@uunet.uu.net
Subject: Help with execute.c

The file execute.c in the server code has a comment that says something like:
  For OVERVIEW -- see execute.txt
I was wondering if this file exists and whether I could get a copy to help me
solve my problem, which I will now describe.

I have an API that I have hooked up to MOO via a builtin that I added called
o2_request(). I can call my API without problems. I have added a callback
facility that will let my API "call back" to a specific object:verb pair in
MOO and allow MOO to return a function value (this call is synchronous). The
callback is implemented with the run_server_task() routine (in tasks.c, I
believe) and works wonderfully, except when the callback is the direct result
of an o2_request() builtin call from MOO.

In this case, the callback executes fine, but when o2_request() returns, the
execution context has been erased (by the run_server_task, I surmise) and any
subsequent code in the o2_request-ing verb is not executed. In other words,
MOO-verb X calls O2-routine Y, which causes a callback to MOO-verb Z. When
control is returned from Y to X, X has lost its place (RUN_ACTIV?) and the
remaining X code is not executed.

I'm looking for either:
 A) A code fragment that I can place around my o2_request() builtin that will
    save/restore any execution context that run_server_task() might disturb.
 B) An explanation of how call_verb() works, because it seems that it might
    be more appropriate for my purposes, as it works within the context of
    an executing code stream.
 C) A new routine, similar to run_server_task, that can be called safely from
    within an execution stream, or by a separately generated event (as in the
    case of an AppleEvent).
 D) A copy of the execute.txt, so I can try to figure this out, if nothing else.

Thanks for any help you can give.
=================================
Dan "Bud" Keith - Odesta Corporation
..mcdchg!ecgcurly!odgate!dbk
Our choice: Free America, or Drug-free Amerika

From pavel@parc.xerox.com Wed Sep 25 12:04:10 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA04802; Wed, 25 Sep 91 12:04:09 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11822>; Wed, 25 Sep 1991 12:02:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11789>; Wed, 25 Sep 1991 12:00:13 PDT
Received: by lambda.parc.xerox.com id <58370>; Wed, 25 Sep 1991 11:58:09 -0700
X-Ns-Transport-Id: 08002008D0FD0010FCA8
In-Reply-To: <9109251527.AA17533@odgate.odesta.com>
Message-Id: <91Sep25.115809pdt.58370@lambda.parc.xerox.com>
Date: 	Wed, 25 Sep 1991 11:58:01 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: Moo-Cows@parc.xerox.com
Subject: Re: Help with execute.c

Dan Keith writes:
> The file execute.c in the server code has a comment that says something like:
>   For OVERVIEW -- see execute.txt
> I was wondering if this file exists and whether I could get a copy to help me
> solve my problem, which I will now describe.

I'm afraid that file no longer exists, unless jug (the author of execute.c, my
summer intern this year) made a backup copy somewhere.  I hadn't realized that
that comment was in there; I would have included a copy of that file if I had.

> I have an API that I have hooked up to MOO via a builtin that I added called
> o2_request(). I can call my API without problems. I have added a callback
> facility that will let my API "call back" to a specific object:verb pair in
> MOO and allow MOO to return a function value (this call is synchronous). The
> callback is implemented with the run_server_task() routine (in tasks.c, I
> believe) and works wonderfully, except when the callback is the direct result
> of an o2_request() builtin call from MOO.

Right.  In order for the server to be able to suspend a task at any time, we
must ensure that the *entire* state of the computation is recorded in the
interpreter's stack array.  In particular, it is not permissible for some of
that state to reside on the C execution stack.  Consider, then, how a primitive
like `create()' is implemented.

Recall that create() must invoke the :initialize verb on the newly-created
object.  If we did this in the obvious way, with the implementation of create()
recursively calling the interpreter, some of the state of the task (in
particular, the fact that we're inside the create() primitive) would be on the
C stack, rather than the MOO stack.  Instead, create() calls call_verb() to
push a new activation record on the MOO stack, calling new-object:initialize.
The create() primitive then returns to the interpreter, requesting that
create() be re-invoked once the current verb call returns.

Each invocation of a primitive provides three parameters: a MOO value, a
`program counter', and a piece of primitive-specific data.  On the first,
normal invocation, the MOO value is the list of arguments, the program counter
is zero, and the primitive-specific data is null.  When a primitive uses
call_verb to push a new frame, it passes several arguments:
	-- the object and verb-name to call,
	-- a list of arguments to pass,
	-- a new `program counter' to use when the primitive is reinvoked, and
	-- the primitive-specific data to pass in that reinvocation.
Thus, when the primitive-initiated verb-call returns, the primitive will be
called again, passing the result of the verb-call and the program counter and
data given to call_verb by the primitive.  The primitive can use the program
counter argument to distinguish between the multiple ways in which it can be
invoked.  The primitive-specific data mechanism is supplied so that the
primitive can `remember' information from one invocation to the next.

The most complex use of this protocol is in the implementation of the move()
primitive, which must in general make *three* calls to verbs during its
processing (:accept, :exitfunc, and :enterfunc).

> I'm looking for either:
>  A) A code fragment that I can place around my o2_request() builtin that will
>     save/restore any execution context that run_server_task() might disturb.

This can't be done properly for the reasons given above.

>  B) An explanation of how call_verb() works, because it seems that it might
>     be more appropriate for my purposes, as it works within the context of
>     an executing code stream.

See above.

>  C) A new routine, similar to run_server_task, that can be called safely from
>     within an execution stream, or by a separately generated event (as in the
>     case of an AppleEvent).

Again, I don't believe that something like this can be done properly.

>  D) A copy of the execute.txt, so I can try to figure this out, if nothing
>     else.

Sorry...

Dan, feel free to write me directly for more help on solving the problem for
your specific application.

	Pavel

From jb7w+@andrew.cmu.edu Thu Sep 26 05:37:31 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <jb7w+@andrew.cmu.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA06444; Thu, 26 Sep 91 05:37:30 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11557>; Thu, 26 Sep 1991 05:36:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11551>; Thu, 26 Sep 1991 05:31:26 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Thu, 26 Sep 1991 05:28:25 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11540>; Thu, 26 Sep 1991 05:28:02 PDT
Received: from andrew.cmu.edu ([128.2.11.131]) by alpha.xerox.com with SMTP id <11540>; Thu, 26 Sep 1991 05:27:26 PDT
Received: by andrew.cmu.edu (5.54/3.15) id <AA01875> for moo-cows.PARC@xerox.com; Thu, 26 Sep 91 08:27:17 EDT
Received: via switchmail; Thu, 26 Sep 1991 08:27:15 -0400 (EDT)
Received: from ccon.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.EcsR7Sm00Vo9Q0WVgl>;
          Thu, 26 Sep 1991 08:26:08 -0400 (EDT)
Received: from ccon.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr24/jb7w/.Outgoing/QF.kcsR7:u00Vo98J5mMa>;
          Thu, 26 Sep 1991 08:25:47 -0400 (EDT)
Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.ccon.weh.andrew.cmu.edu.pmax.ul4
          via MS.5.6.ccon.weh.andrew.cmu.edu.pmax_ul4;
          Thu, 26 Sep 1991 08:25:46 -0400 (EDT)
X-Ns-Transport-Id: 08002008D0FD001105F4
In-Reply-To: <91Sep25.100716pdt.58370@lambda.parc.xerox.com>
Message-Id: <gcsR7_e00Vo9IJ5mFx@andrew.cmu.edu>
References: <91Sep25.100716pdt.58370@lambda.parc.xerox.com>
Date: 	Thu, 26 Sep 1991 05:25:46 PDT
From: Joseph Gerard Behrmann <jb7w+@andrew.cmu.edu>
To: moo-cows.PARC@xerox.com
Subject: Re: Odd occurance...


Pavel Curtis <pavel@parc.xerox.com> writes:
> Joseph Gerard Behrmann writes:
> sends a line of input upon connection.  The default implementation of
> #0:do_login_command prints the $welcome_message if (a) the input is a null
> line, (b) the command is `help', or (c) the command is unrecognized.  Check t
> see if your client is sending such a line upon connection.  The server itself

Yup, it does, thanks for the help on that problem.

> 
> > I also have the same problem with my test MOO, I got the newqserver sources
> > and compiled them, ran the server, and no problem, until I it hit an error
> > traceback in a verb I called.  Then the server hung ...
> 
> I'm more interested in this problem than the other.  Are you running 1.4.5?
> Is the hang reproducible?

Yup I was running 1.4.5, I got it the minute I got the mail on it.  I
couldn't reproduce the error (I really didn't try that hard, I was
programming and really _didn't_ want it to happen again).  I just
modified one line of code and then I tried to run it, when zap it gave
me the trace answer (which was right by the way) and then wouldn't
accept any commands.  I could even connect to it, but it wouldn't
completely log me in as it wouldn't do any commands (hope that fact
might be significant).  I finally just had to kill it.

> 
> > ... started with my save of the db from about 20 minutes before and the
> > multiple $welcome_messages showed up when I logged on.  It had not done that
> > before.  Anyone have any clues about this?  I was wondering if it might be a
> > symptom of db corruption or something...
> 
> I doubt that any random kind of DB corruption could cause this; it would have
> to change the code for #0:do_login_command in a way that was syntactically
> correct and had this odd behavior.
> 
>         Pavel

Never really thought of that, but yeah, I guess that its really easy
to tell if the db is corrupt.

Thanks for the help, If I can reproduce the error, I'll tell you.
That's what I like about MOO, there's a lot of really clueful people
hanging around to talk to about it.

EVERYTHING NOT FORBIDDEN IS COMPULSORY - A little ant
"All that we see or seem is but a dream within a dream." - E.A.P.
						Joe
						jb7w+@andrew.cmu.edu

From lro@sirius.melb.bull.oz.au Mon Sep 30 00:29:51 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <lro@sirius.melb.bull.oz.au>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA12996; Mon, 30 Sep 91 00:29:50 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11524>; Mon, 30 Sep 1991 00:28:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11523>; Mon, 30 Sep 1991 00:19:43 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 00:17:11 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11523>; Mon, 30 Sep 1991 00:16:48 PDT
Received: from sol.melb.bull.oz.au ([134.211.128.1]) by alpha.xerox.com with SMTP id <11522>; Mon, 30 Sep 1991 00:14:43 PDT
Received: from sirius.melb.bull.oz.au by sol.melb.bull.oz.au (5.65+/Bull-1.1)
	id AA24932; Mon, 30 Sep 91 17:14:20 +1000
Received: from sx6.YP.melb.bull.oz by sirius (4.0/SMI-4.0)
	id AA15418; Mon, 30 Sep 91 17:13:32 EST
X-Ns-Transport-Id: 08002008D0FD00112A4F
Message-Id: <Q8E6C024@sx6>
Date: 	Mon, 30 Sep 1991 15:13:32 PDT
From: lro@melb.bull.oz.au (Liam Routt)
Sender: lro@sirius.melb.bull.oz.au
To: moo-cows.PARC@xerox.com
Subject: Non-networked?

    I have only just joined this discussion...  I've found the archives
intriguing, especially when they mention the possibility of a non-networked
version of LambdaMOO...

    Is such an enhancement (for that is how I see it) on the near horizon?
Or should I resign myself to hacking into the BSD-network parts of the code
myself (and the multi-month wait that implies :) )?

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


From jsmart@iastate.edu Mon Sep 30 00:57:21 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <jsmart@iastate.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13036; Mon, 30 Sep 91 00:57:20 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11525>; Mon, 30 Sep 1991 00:56:30 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11524>; Mon, 30 Sep 1991 00:50:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 00:46:34 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11522>; Mon, 30 Sep 1991 00:46:10 PDT
Received: from iastate.edu ([129.186.2.32]) by alpha.xerox.com with SMTP id <11522>; Mon, 30 Sep 1991 00:45:12 PDT
Received: by iastate.edu with sendmail-5.57/4.7 
	id <AA02859@iastate.edu>; Mon, 30 Sep 91 02:45:06 -0500
X-Ns-Transport-Id: 08002008D0FD00112A61
Message-Id: <9109300745.AA02859@iastate.edu>
Date: 	Mon, 30 Sep 1991 00:45:03 PDT
From: jsmart@iastate.edu
To: moo-cows.parc@xerox.com
Subject: Re: non-networked

>    I have only just joined this discussion...  I've found the archives
>intriguing, especially when they mention the possibility of a non-networked
>version of LambdaMOO...
>
>    Is such an enhancement (for that is how I see it) on the near horizon?
>Or should I resign myself to hacking into the BSD-network parts of the code
>myself (and the multi-month wait that implies :) )?
>
>                                            Liam Routt
>        "Murder by Pirates is Good"         Senior Software Engineer
>                -The Princess Bride         Bull Information Systems
>                                            Melbourne, AUSTRALIA
>                                            (also Repulsion)

Hmmm...  I'm not even close to a comp.sci major, but if he is talking about
using MOO as a shell (like M-DOS or something like that)  I think it would be
worth looking into.  User-friendly at it's best.  programs would be "tools". 
Text files could be picked up, put down, read, glanced at, burned, whatever.

Either this is a terribly unoriginal idea or it is so obvious that no one has
ever considered it before.  Why isn't there any type of virtual shell existing
today?

							-John

From STJS@vm.marist.edu Mon Sep 30 11:10:35 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <STJS@vm.marist.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13926; Mon, 30 Sep 91 11:10:32 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11550>; Mon, 30 Sep 1991 11:09:33 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11570>; Mon, 30 Sep 1991 11:03:27 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 11:01:07 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11574>; Mon, 30 Sep 1991 11:00:25 PDT
Received: from VM.MARIST.EDU ([148.100.1.2]) by alpha.xerox.com with SMTP id <11576>; Mon, 30 Sep 1991 10:59:35 PDT
Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R1)
   with BSMTP id 2687; Mon, 30 Sep 91 13:59:58 EDT
Received: by MARIST (Mailer R2.07) id 5015; Mon, 30 Sep 91 13:59:57 EDT
X-Ns-Transport-Id: 08002008D0FD00112FD4
Message-Id: <91Sep30.105935pdt.11576@alpha.xerox.com>
Date: 	Mon, 30 Sep 1991 10:57:49 PDT
From: "Joey J. Stanford, Systems Operational Services" <STJS@vm.marist.edu>
To: "An Utter MOO of a good time...." <MOO-COWS@xerox.com>
Subject: memory lapse


Quicky question.....

 how does one effect a "this:announce_all" (as opposed to a "player:announce_al
l")

 I want an object to go to one "room", issue messages, and then leave. The
object and the player who called it's verb will be in two separate "rooms".

jj

From yduj@lucid.com Mon Sep 30 11:25:12 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13953; Mon, 30 Sep 91 11:25:10 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11594>; Mon, 30 Sep 1991 11:24:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11592>; Mon, 30 Sep 1991 11:21:17 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 11:18:14 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11594>; Mon, 30 Sep 1991 11:17:42 PDT
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11586>; Mon, 30 Sep 1991 11:16:17 PDT
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA01695g; Mon, 30 Sep 91 11:10:30 PDT
Received: by boston-harbor id AA10242g; Mon, 30 Sep 91 14:17:01 EDT
X-Ns-Transport-Id: 08002008D0FD0011301E
In-Reply-To: "\"Joey J. Stanford, Systems Operational Services\"'s message of Mon, 30 Sep 1991 10:57:49 PDT <91Sep30.105935pdt.11576@alpha.xerox.com>n"
Message-Id: <9109301817.AA10242@boston-harbor>
Date: 	Mon, 30 Sep 1991 11:17:01 PDT
From: Judy Anderson <yduj@lucid.com>
To: STJS@vm.marist.edu
Cc: moo-cows.parc@xerox.com
Subject: memory lapse

I think you should provide some more information about what you are
doing; your message is confusing.  'this' is a built in variable,
which is set to the object on which the verb was invoked.  Thus, if
the object in question is a descendent of room, you just say
'this:announce_all(<announce all args>);' in your program; the
announcement gets made to that room, and that room only.  What did you
have in mind for the value of 'this'?  If it is not a room, then it
may need to do 'this.location:announce_all(<args>);'

I think you should ask "long involved questions"; your quickies leave
me completely baffled!

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'


From Don.Hopkins@eng.sun.com Mon Sep 30 12:49:46 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <Don.Hopkins@eng.sun.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14173; Mon, 30 Sep 91 12:49:45 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11599>; Mon, 30 Sep 1991 12:47:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11571>; Mon, 30 Sep 1991 12:44:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 12:41:42 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11623>; Mon, 30 Sep 1991 12:41:06 PDT
Received: from Sun.COM ([192.9.9.1]) by alpha.xerox.com with SMTP id <11612>; Mon, 30 Sep 1991 12:40:14 PDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA03441; Mon, 30 Sep 91 12:40:05 PDT
Received: from poit.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA03024; Mon, 30 Sep 91 12:39:51 PDT
Received: by poit.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00493; Mon, 30 Sep 91 12:45:25 PDT
X-Ns-Transport-Id: 08002008D0FD00113191
In-Reply-To: "jsmart@iastate.edu's message of Mon, 30 Sep 1991 00:45:03 PDT <9109300745.AA02859@iastate.edu>"
Message-Id: <9109301945.AA00493@poit.Eng.Sun.COM>
Date: 	Mon, 30 Sep 1991 12:45:25 PDT
From: Don.Hopkins@eng.sun.com (Don Hopkins)
To: jsmart@iastate.edu
Cc: moo-cows.parc@xerox.com
Subject: moosh

> Either this is a terribly unoriginal idea or it is so obvious that
> no one has ever considered it before.  Why isn't there any type of
> virtual shell existing today?

It's just too good an idea for anyone to take seriously, that's all.

	-Don

From ken@imsa.edu Mon Sep 30 13:27:25 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <ken@imsa.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14272; Mon, 30 Sep 91 13:27:24 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11622>; Mon, 30 Sep 1991 13:26:18 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11618>; Mon, 30 Sep 1991 13:21:57 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 13:19:34 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11578>; Mon, 30 Sep 1991 13:19:13 PDT
Received: from imsa.edu ([143.195.1.2]) by alpha.xerox.com with SMTP id <11615>; Mon, 30 Sep 1991 13:18:38 PDT
Received: by imsa.edu (4.0/SMI-4.0)
	id AA20240; Mon, 30 Sep 91 15:17:46 CDT
X-Ns-Transport-Id: 08002008D0FD0011321F
Message-Id: <9109302017.AA20240@imsa.edu>
Date: 	Mon, 30 Sep 1991 13:17:46 PDT
From: ken@imsa.edu (Kenneth C. Schalk)
To: jsmart@iastate.edu, moo-cows.parc@xerox.com
Subject: Re: non-networked

jsmart@iastate.edu writes:
>Hmmm...  I'm not even close to a comp.sci major, but if he is talking about
>using MOO as a shell (like M-DOS or something like that)  I think it would be
>worth looking into.  User-friendly at it's best.  programs would be "tools".
>Text files could be picked up, put down, read, glanced at, burned, whatever.
>
>Either this is a terribly unoriginal idea or it is so obvious that no one has
>ever considered it before.  Why isn't there any type of virtual shell existing
>today?

    Oh this has certainly been thought of, and a few attempts at
implementations have even been tried.  (At least in my interpretation,
this is what Gibson meant when he talked about cyberspace.)  No one
has done it properly yet though.  Mainly that's because to do a really
good job, you should probably start from scratch with a totally new OS
as opposed to laying on top of some existing system.  (Or make a total
kludgification that hides just about everything that actually goes on
and puts up a seperate facade for the user.  (For you GUI flamers out
there, no I don't think that argument applies to GUIs.))  Also there's
the fact that for a lot of ordinary operations, the interface just
isn't fast enough yet.  (Isn't 'cat foo' a lot faster than 'get foo;
read foo'?)  Someday, when someone develops DNI and makes it
affordable, everything will be done this way (or so I think).
    Specifically, converting MOO to a shell doesn't really make sense.
You might as well start again from the ground up if what you want is
an interface to lay on top of a UNIX system.  (Unless you want a huge
MOO db with an object to represent each file in your filesystem
...yech.)

    Anyway, let's stop this digression here before before moo-cows
becomes talk.vr.misc...

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/ Kenneth C Schalk, aka ///"Is conciousness just a special form of ///
\ Xorian|Darkman on MUDs \\  hallucination?"--Frank Herbert        \\\  //-\
////////////////////////////////////////////////////////////////////// //-O|
\ ken@imsa.edu \\\\\\\ Discalimer: All spellings expressed are those\\ |   |
/ schalk@mcs.anl.gov / of the author, although not even he has any  //  \_/
\ k-schalk@uiuc.edu \\ idea where they come from.                   \\
//////////////////////////////////////////////////////////////////////
    	    	    	    	    	    ^
    	        	    	 (Look Frand|)

From pavel@parc.xerox.com Mon Sep 30 14:13:15 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14432; Mon, 30 Sep 91 14:13:13 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11644>; Mon, 30 Sep 1991 14:11:49 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11625>; Mon, 30 Sep 1991 14:08:11 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 30 Sep 1991 14:05:10 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11635>; Mon, 30 Sep 1991 14:04:44 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11636>; Mon, 30 Sep 1991 14:04:00 PDT
Received: by lambda.parc.xerox.com id <58369>; Mon, 30 Sep 1991 14:03:05 -0700
X-Ns-Transport-Id: 08002008D0FD001132C4
In-Reply-To: <Q8E6C024@sx6>
Message-Id: <91Sep30.140305pdt.58369@lambda.parc.xerox.com>
Date: 	Mon, 30 Sep 1991 14:02:55 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: lro@melb.bull.oz.au
Cc: moo-cows.PARC@xerox.com
Subject: Re: Non-networked?

Liam Routt writes:
>     I have only just joined this discussion...  I've found the archives
> intriguing, especially when they mention the possibility of a non-networked
> version of LambdaMOO...
> 
>     Is such an enhancement (for that is how I see it) on the near horizon?
> Or should I resign myself to hacking into the BSD-network parts of the code
> myself (and the multi-month wait that implies :) )?

I'm never sure just what people mean when they say `non-networked' in this
context, I suspect because there are two reasonable meanings floating around
out there:

1) A single-user MUD that only accepts `connections' from the terminal on which
   the server was started.  That is, once you start the server, it sits in a
   loop, pretending that you've just connected to the MUD from `outside'.  You
   can log in as usual and, when you @quit, it once again `connects' you.  You
   break out of the loop by logging in as a wizard and shutting down the
   server.

2) A multi-user MUD that accepts some kind of non-network connections from
   users logged into the same machine as the server (perhaps in addition to the
   usual kinds of network connections).

As I've said many times before, version (1) of this idea is quite easy to
write; see the README file that comes with the server for details on how to
build such a trivial `network' module.

Version (2) is a bit stranger, since I don't quite understand how it's supposed
to work.  How do users make their `connections' to the server?  Do they have to
use some special client that can communicate with the local server?  Clearly,
there are many ways for the actual communication to work; I'm just wondering if
people have in mind allowing normal MUD clients to work with this server in
some way.

In any case, even version (2) shouldn't be all that hard to write, either as a
completely new network module or as a small set of changes to the bsd_network.c
module that comes with the release.

I am willing to distribute with the main release any new network modules people
write, so feel free to send them to me if you write them.

	Pavel

From sfwhite@watcgl.waterloo.edu Thu Oct  3 11:54:13 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <sfwhite@watcgl.waterloo.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA21930; Thu, 3 Oct 91 11:54:12 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11622>; Thu, 3 Oct 1991 11:53:21 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11620>; Thu, 3 Oct 1991 11:47:03 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Thu, 3 Oct 1991 11:42:33 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11626>; Thu, 3 Oct 1991 11:42:14 PDT
Received: from watcgl.waterloo.edu ([129.97.140.64]) by alpha.xerox.com with SMTP id <11628>; Thu, 3 Oct 1991 11:41:19 PDT
Received: by watcgl.waterloo.edu
	id <AA00267>; Thu, 3 Oct 91 14:39:33 -0400
X-Ns-Transport-Id: 08002008D0FD00115EC3
Message-Id: <9110031839.AA00267@watcgl.waterloo.edu>
Date: 	Thu, 3 Oct 1991 11:39:33 PDT
From: Stephen White <sfwhite@watcgl.waterloo.edu>
To: jsmart@iastate.edu, ken@imsa.edu, moo-cows.parc@xerox.com
Subject: Re: non-networked

jsmart@iastate.edu writes:

> Hmmm...  I'm not even close to a comp.sci major, but if he is talking about
> using MOO as a shell (like M-DOS or something like that)  I think it would be
> worth looking into.  User-friendly at it's best.  programs would be "tools".
> Text files could be picked up, put down, read, glanced at, burned, whatever.

a curious thought.
imagine "compile code.c with gcc" or "hit troll with emacs source".

ken@imsa.edu writes:

> Oh this has certainly been thought of, and a few attempts at
> implementations have even been tried.  (At least in my interpretation,
> this is what Gibson meant when he talked about cyberspace.)

i'll take this as a compliment :)

-- stephen

From dugan@archimedes.math.uiuc.edu Thu Oct  3 16:55:24 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <dugan@archimedes.math.uiuc.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA22683; Thu, 3 Oct 91 16:55:23 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11609>; Thu, 3 Oct 1991 16:54:22 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11620>; Thu, 3 Oct 1991 16:51:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Thu, 3 Oct 1991 16:49:10 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11609>; Thu, 3 Oct 1991 16:48:41 PDT
Received: from ux1.cso.uiuc.edu ([128.174.5.59]) by alpha.xerox.com with SMTP id <11609>; Thu, 3 Oct 1991 16:47:50 PDT
Received: from archimedes.math.uiuc.edu by ux1.cso.uiuc.edu with SMTP id AA09217
  (5.65c/IDA-1.4.4 for <moo-cows.parc@xerox.com>); Thu, 3 Oct 1991 18:47:16 -0500
Received: by archimedes.math.uiuc.edu (4.1/SMI-4.1)
	id AA01435; Thu, 3 Oct 91 18:41:26 CDT
X-Mailer: ELM [version 2.3 PL11]
X-Ns-Transport-Id: 08002008D0FD001163BF
Message-Id: <9110032341.AA01435@archimedes.math.uiuc.edu>
Date: 	Thu, 3 Oct 1991 16:41:25 PDT
From: dugan@archimedes.math.uiuc.edu (Jon Dugan)
To: moo-cows.parc@xerox.com
Subject: Speaking of non-networked
Reply-To: j-dugan@uiuc.edu


	This may appear to be a foolish question, and it indeed maybe
	a foolish question -- but that never stopped me before...

	I was wondering how difficult it would be to compile the MOO
	server under MS-DOS (non-networked obviously).  I haven't 
	really looked at the code or anything.   But this seems like
	it could be really cool...  It would keep me off my modem and
	my roommate would like that...  

	Also such a setup could also allow people to experiment with
	MOO at their leisure.  

	Finally... with a (probably) good deal of work it might be 
	possible to export stuff done in a MS-MOO db to a separate
	file and then perhaps upload the file in some manner to a
	networked MOO.

	It seems to me that such an idea would conceivably increase
	the number of quality MOOprogrammers.

	Tell me what you think.  If this is completly delerious it is
	because I'm going on 4.5 hours of sleep (exams create a vacuum).

	ttfn,

		Jon / The_Gray_Mage

From seth@alchemy.tn.cornell.edu Thu Oct  3 18:45:52 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <seth@alchemy.tn.cornell.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA23006; Thu, 3 Oct 91 18:45:51 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11620>; Thu, 3 Oct 1991 18:44:56 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12444>; Thu, 3 Oct 1991 18:43:12 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Thu, 3 Oct 1991 18:35:08 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11620>; Thu, 3 Oct 1991 18:34:34 PDT
Received: from alchemy.tn.cornell.edu ([128.84.253.9]) by alpha.xerox.com with SMTP id <12453>; Thu, 3 Oct 1991 18:33:35 PDT
Received: by alchemy.tn.cornell.edu (4.1/SMI-4.1)
	id AA01230; Thu, 3 Oct 91 21:35:13 EDT
X-Ns-Transport-Id: 08002008D0FD001164F6
Message-Id: <9110040135.AA01230@alchemy.tn.cornell.edu>
Date: 	Thu, 3 Oct 1991 18:35:13 PDT
From: seth@alchemy.tn.cornell.edu (Seth Cohn)
To: moo-cows.parc@xerox.com
Subject: MSdos MOO (or other pc types)


I was hoping the same, but after looking at the code ( and having a few others
do the sme who are more PC oriented then me (mac
's forver!) we realized that the unix processes are just too hard to fake out..
Unix is as Unix does.  Maybe a XENIX version could be done... but not an MSDOS
one.. (or Mac, or etc...)  I wish it could.  Personally, I'm looking
into a Sun workstation, and I'm thinking seriously about
replacing my BBS (with 2 lines on a mac)  with a MOO. Would this be the first
direct dial moo?

Seth

From tellab5!odgate!dbk@uunet.uu.net Fri Oct  4 02:29:23 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <tellab5!odgate!dbk@uunet.uu.net>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA23648; Fri, 4 Oct 91 02:29:20 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11604>; Fri, 4 Oct 1991 02:28:20 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11604>; Fri, 4 Oct 1991 02:26:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Fri, 4 Oct 1991 02:19:46 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11603>; Fri, 4 Oct 1991 02:19:19 PDT
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11604>; Fri, 4 Oct 1991 02:18:42 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA19670; Fri, 4 Oct 91 05:18:41 -0400
Received: from tellab5.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 051749.22587; Fri, 4 Oct 1991 05:17:49 EDT
Received: by tellab5.CHI.IL.US (smail2.5)
	id AA14907; 4 Oct 91 03:25:47 CDT (Fri)
X-Ns-Transport-Id: 08002008D0FD001167E5
Message-Id: <9110040737.AA08205@odgate.odesta.com>
Date: 	Fri, 4 Oct 1991 00:37:50 PDT
From: odgate!dbk@uunet.uu.net (Dan Keith)
Sender: tellab5!odgate!dbk@uunet.uu.net
To: moo-cows.parc@xerox.com
Subject: re: MSdos MOO (or other pc types)

mtcchi!uunet!alchemy.tn.cornell.edu!seth (Seth Cohn) writes:


>I was hoping the same, but after looking at the code ( and having a few others
>do the sme who are more PC oriented then me (mac
>'s forver!) we realized that the unix processes are just too hard to fake
>out.

>Unix is as Unix does.  Maybe a XENIX version could be done... but not an MSDOS
>one.. (or Mac, or etc...)  I wish it could.  Personally, I'm looking
           ^^^
>Seth

Actually, it's pretty easy to make a standalone version and/or a networked
version on a Mac (and on a PC, as well). I have an MPW tool that runs MOO
standalone using stdio to support 1 "connect". I have an MPW tool that runs
MOO over TCP/IP (I haven't used it since version 1.1 or 1.2 of the
server, so I doubt if it'll work.) and allows telnetting in from another
Mac or even a Unix client.

I'm currently experimenting with a graphical MOO that allows windows,
buttons, etc to be created and hooked up to MOO objects. I'm using it as
prototype for a higher-performance interactive application-design
system.

The steps I took to port it (standalone and networked) were:
I) Any routine which didn't make sense on the mac, I stubbed out with some
appropriate dummy routine. In the case of fork(), which is used by the
database dumping routine, I simply decided that a @dump_database or
@shutdown would require the user(s) to wait.

II) I replaced all of the 'unixy' calls in bsd-network.c with calls to a
package I wrote called SKT, which emulates the socket calls, but works with
stdio, MacTCP, as well as an in-memory pseudo-socket that is used in the
graphical MOO. Note: I did this instead of replacing bsd-network.c (as
suggested by Pavel) because IMHO, bsd-network.c has a lot of reusable code
that I didn't want to rewrite. However, without the initial bsd-network.c
split, I would have had a tough time knowing where to start.

III) On the Mac, you should build a "real" event loop in server.c so that
other processes on the machine can get some time.

I've found that a standalone MOO (especially on a real computer, like the
Mac) is very useful for developing and experimenting with MOO programming.
I haven't had much chance to program on LambdaMOO, since my internet
connect is somewhat tenuous and possibly illegal (just kidding, Feds).

I think a direct-dial MOO would be great, both as a game, and as a flexible
bulletin board system. In fact, you could replace your BBS with a game AND
a BBS. Of course, you'd have to add BBSish primitives to the MOO, but
that's pretty straightforward (Hurray for the breakup of the bf_*.c decks).

Good Luck.

Dan Keith - Odesta Corporation
..mcdchg!ecgcurly!odgate!dbk (or even better, reply to this message)
=========================================================================
Our choice: Free America, or Drug-Free Amerika

Prohibition goes beyond the bounds of reason in that it attempts to control
a man's appetite by legislation and makes crimes out of things that are not
crimes. A prohibition law strikes a blow at the very principles upon which our
government was founded. - Abraham Lincoln

From tellab5!odgate!dbk@uunet.uu.net Fri Oct  4 10:44:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <tellab5!odgate!dbk@uunet.uu.net>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA24461; Fri, 4 Oct 91 10:44:43 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11671>; Fri, 4 Oct 1991 10:43:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11660>; Fri, 4 Oct 1991 10:38:08 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 4 Oct 1991 10:32:51 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11660>; Fri, 4 Oct 1991 10:32:16 PDT
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11665>; Fri, 4 Oct 1991 10:31:26 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA19815; Fri, 4 Oct 91 13:31:28 -0400
Received: from tellab5.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 133027.5793; Fri, 4 Oct 1991 13:30:27 EDT
Received: by tellab5.CHI.IL.US (smail2.5)
	id AA27771; 4 Oct 91 11:29:19 CDT (Fri)
X-Ns-Transport-Id: 08002008D0FD00116CCE
Message-Id: <9110041623.AA13423@odgate.odesta.com>
Date: 	Fri, 4 Oct 1991 09:23:58 PDT
From: odgate!dbk@uunet.uu.net (Dan Keith)
Sender: tellab5!odgate!dbk@uunet.uu.net
To: moo-cows.parc@xerox.com

Seth (seth@alchemy.tn.cornell.edu (Seth Cohn)) writes:

>please send message, it got garbled at the end.
>I'm curious... you say you dummyed fork(), that's the sorta thing I DIDN"T
>want to do, then it won't run many things...
>Seth

Did you want me to resend the message? If so, it is being resent under
separate cover.

With regards to fork(), I dummied the Unix fork() call, which (so far as I
can tell) is ONLY used in server.c for the purpose of dumping the database.
When the dump_database() function is executed (in response to an @shutdown
or @dump??? verb), the server creates a forked copy of the process (and
therefore the in-memory database). This forked copy executes asynchronously
(on a Unix box, at least) and proceeds to dump the database, while the
parent process continues executed and handling the 'game'.

I think you might be mistakenly assuming that the unix fork() primitive is
needed to implement the MOO fork...endfork construct; if so, let me correct
you. The MOO fork...endfork is emulated within the MOO virtual machine and
does not require any unix-specific stuff. Thus, the only drawback to a
dummied fork() is that you have to wait for the database to dump (a few
minutes on a MacIIci).

If I am incorrect in my assumption about your assumption about fork being
related to 'it won't run many thing...', please explain.

P.S. I am posting this to MOO-cows, just in case anybody else is
interested. This also gives the LambdaWizzes a chance to check my answer,
in case I'm wrong or don't have the whole story.

Dan Keith - Odesta Corporation
.mcdchg!ecgcurly!odgate!dbk (or even better, reply to this message)
=========================================================================
Our choice: Free America, or Drug-Free Amerika

Prohibition goes beyond the bounds of reason in that it attempts to control
a man's appetite by legislation and makes crimes out of things that are not
crimes. A prohibition law strikes a blow at the very principles upon which our
government was founded. - Abraham Lincoln

---


From parc.xerox.com.PARC@xerox.com Thu Oct 10 11:39:39 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com.PARC@xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14088; Thu, 10 Oct 91 11:39:38 PDT
Errors-To: parc.xerox.com.PARC@xerox.com
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11609>; Thu, 10 Oct 1991 11:39:04 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11611>; Thu, 10 Oct 1991 11:35:17 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Thu, 10 Oct 1991 11:33:08 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11556>; Thu, 10 Oct 1991 11:32:39 PDT
Received: from TAUNIVM.TAU.AC.IL ([132.66.32.4]) by alpha.xerox.com with SMTP id <11595>; Thu, 10 Oct 1991 11:31:52 PDT
Received: from ccsg.tau.ac.il by TAUNIVM.TAU.AC.IL (IBM VM SMTP R1.2.2MX) with TCP; Thu, 10 Oct 91 20:31:27 IST
X-Mailer: ELM [version 2.3 PL11]
X-Ns-Transport-Id: 08002008D0FD0011B1A5
Xns-Originator: parc.xerox.com.PARC@Xerox.com
Errors-To: parc.xerox.com.PARC@xerox.com
Message-Id: <9110101827.AA11040@ccsg.tau.ac.il>
Date: 	Thu, 10 Oct 1991 11:27:21 PDT
From: Dov Samet <samet@ccsg.tau.ac.il>
Sender: <@taunivm.tau.ac.il:samet@ccsg.tau.ac.IL>
To: moo-cows.parc@xerox.com
Subject: Getting the player's perms.

This might not look like a good idea to some people but I'll write it anyway...

  Add a new function to $permission_utils, :ask_set_perms(). It will ask
the player for his permission to set the task perms to his perms. This can
for verbs that need to change things on a player. The verb will prompt the
user and warn him that he MUST @list the verb and understand exactly what it
does. I'm not really sure if this verb should be made because it could be
used by crackers, but then again, it can help very much.

-----
 Internet:  SAMET@ccsg.tau.ac.il              In MUDs:  ZigZag


From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Wed Oct 16 13:38:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA25590; Wed, 16 Oct 91 13:38:43 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11910>; Wed, 16 Oct 1991 13:38:03 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11887>; Wed, 16 Oct 1991 13:32:12 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Wed, 16 Oct 1991 13:22:30 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11902>; Wed, 16 Oct 1991 13:21:47 -0700
Received: by sonne (4.1/1.36)
	id AA20065; Wed, 16 Oct 91 15:21:43 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0011FA7E
Message-Id: <9110162021.AA20065@sonne>
Date: 	Wed, 16 Oct 1991 13:21:42 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: Texinfo -> something else

Um, Texinfo is nice and everything, but does anyone have any quickie ways to
convert a texinfo doc (I refer to the ones available in parcftp.../contrib) to
something friendly like postscript?

Or should I just bite the bullet and get tex.

OK, not really a moo question, but it's at least tangent ;).

-- 
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               Ignorance & Fear.  Fear & Ignorance.

From pavel@parc.xerox.com Wed Oct 16 17:15:49 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA26249; Wed, 16 Oct 91 17:15:47 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11934>; Wed, 16 Oct 1991 17:15:17 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11941>; Wed, 16 Oct 1991 17:11:27 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Wed, 16 Oct 1991 17:02:31 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11934>; Wed, 16 Oct 1991 17:01:55 -0700
Received: by lambda.parc.xerox.com id <58369>; Wed, 16 Oct 1991 17:01:44 -0700
X-Ns-Transport-Id: 08002008D0FD0011FDEE
In-Reply-To: <9110162021.AA20065@sonne>
Message-Id: <91Oct16.170144pdt.58369@lambda.parc.xerox.com>
Date: 	Wed, 16 Oct 1991 17:01:44 -0700
From: Pavel Curtis <pavel@parc.xerox.com>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu
Cc: moo-cows@parc.xerox.com
Subject: Re: Texinfo -> something else

Other than TeX, there aren't any such useful programs yet.  There is supposed
to be a TeXInfo-to-Troff/Nroff converter at some point, but only an old
obsolete one has been released thus far.

You can, however, convert TeXInfo into formatted ASCII using the program
`makeinfo', which comes as a part of the TeXInfo distribution.  The latest such
distribution is available from prep.ai.mit.edu, directory /u/emacs, in the
file texinfo-2.10.tar.Z.

	Pavel

From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Wed Oct 16 17:26:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB26265; Wed, 16 Oct 91 17:26:38 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11944>; Wed, 16 Oct 1991 17:24:41 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11956>; Wed, 16 Oct 1991 17:23:17 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Wed, 16 Oct 1991 17:21:58 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11915>; Wed, 16 Oct 1991 17:15:06 -0700
Received: by sonne (4.1/1.36)
	id AA21362; Wed, 16 Oct 91 19:15:03 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0011FE14
Message-Id: <9110170015.AA21362@sonne>
Date: 	Wed, 16 Oct 1991 17:15:02 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: Never mind...

Regarding using the editors to edit properties:

Oh, never mind...I found it...:)

-- 
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               Ignorance & Fear.  Fear & Ignorance.

From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Wed Oct 16 17:35:46 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA26279; Wed, 16 Oct 91 17:35:45 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11944>; Wed, 16 Oct 1991 17:35:05 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11934>; Wed, 16 Oct 1991 17:33:23 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Wed, 16 Oct 1991 17:32:14 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11946>; Wed, 16 Oct 1991 17:13:49 -0700
Received: by sonne (4.1/1.36)
	id AA21344; Wed, 16 Oct 91 19:13:43 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0011FE37
Message-Id: <9110170013.AA21344@sonne>
Date: 	Wed, 16 Oct 1991 17:13:42 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: Editing Properties w/ One of the LCore editors

I was hunting and pecking through the LCore help screens when I came across
this blurb:

In addition, individual editors provide their own additional commands for
loading text from places, saving text to places, and various other specialized
functions which are denoted in the above list with (M),(N),(V) according as
they apply to the mail editor, the note editor, or the verb editor,
respectively.


Does this (I hope) imply that I can use one of the editors to edit a
property?

For instance,  could I edit the $welcome_message this way (handy example)?

Thanks.

-- 
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               Ignorance & Fear.  Fear & Ignorance.

From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Wed Oct 16 19:15:26 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA26416; Wed, 16 Oct 91 19:15:23 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11975>; Wed, 16 Oct 1991 19:14:38 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11962>; Wed, 16 Oct 1991 19:13:31 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Wed, 16 Oct 1991 19:12:26 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11978>; Wed, 16 Oct 1991 19:12:07 -0700
Received: by sonne (4.1/1.36)
	id AA21679; Wed, 16 Oct 91 21:12:04 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0011FF26
Message-Id: <9110170212.AA21679@sonne>
Date: 	Wed, 16 Oct 1991 19:12:03 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: A List Editor!

A list editor, a list editor.  My kingdom for a list editor!
:)


-- 
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               Ignorance & Fear.  Fear & Ignorance.

From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Thu Oct 17 12:34:15 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB27728; Thu, 17 Oct 91 12:34:12 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11647>; Thu, 17 Oct 1991 12:33:07 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11607>; Thu, 17 Oct 1991 12:28:15 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Thu, 17 Oct 1991 12:24:41 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11598>; Thu, 17 Oct 1991 12:24:08 -0700
Received: by sonne (4.1/1.36)
	id AA22915; Thu, 17 Oct 91 14:24:06 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD00120911
Message-Id: <9110171924.AA22915@sonne>
Date: 	Thu, 17 Oct 1991 12:24:05 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: @notedit fails to edit description

Hmm, I don't know if this is a bug or what....

According to the helps, @notedit can edit any text property or any property
that is a list of strings.

The .description property is described as being a text string *or* a list of
strings.

Therefore, logically, one ought to be able to use @notedit to edit
the description of an object.

However, notice:

;#2.description = "A simple description."
=>  "A simple description."
look me
A simple description.
He is awake and looks alert.
@notedit #2.description
Couldn't retrieve text:  Type mismatch



Somebody's lying to me here. ;)

It, also, seems to be local to the description property, since I have been
able to edit other text-list properties, such as $note_editor.no_littering_msg.

Somewhat confused.

-- 
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               Ignorance & Fear.  Fear & Ignorance.

From yduj@lucid.com Thu Oct 17 13:15:06 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB27864; Thu, 17 Oct 91 13:15:03 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11617>; Thu, 17 Oct 1991 13:14:22 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11614>; Thu, 17 Oct 1991 13:04:48 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Thu, 17 Oct 1991 13:01:37 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11622>; Thu, 17 Oct 1991 13:01:09 -0700
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA15918g; Thu, 17 Oct 91 13:00:27 PDT
Received: by boston-harbor id AA23699g; Thu, 17 Oct 91 16:01:45 EDT
X-Ns-Transport-Id: 08002008D0FD0012099C
In-Reply-To: "Clay Luther's message of Thu, 17 Oct 1991 12:24:05 -0700 <9110171924.AA22915@sonne>"
Message-Id: <9110172001.AA23699@boston-harbor>
Date: 	Thu, 17 Oct 1991 13:01:45 -0700
From: Judy Anderson <yduj@lucid.com>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu
Cc: moo-cows@parc.xerox.com
Subject: @notedit fails to edit description

Well, it turns out that your example, $note_editor.no_littering_msg,
is in fact a list of strings, rather than just one string.

Strange, though, because @notedit works for me on my string
description.  

  @notedit me.description
  Note Editor

  Do a 'look' to get the list of commands, or 'help' for assistance.

  Now editing "yduJ"(#68).description.  [string mode]


I wonder if Rog added that after the August 26 Core was created.

						Judy.

From parc.xerox.com.PARC@xerox.com Fri Oct 18 07:11:20 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com.PARC@xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA29276; Fri, 18 Oct 91 07:11:17 PDT
Errors-To: parc.xerox.com.PARC@xerox.com
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11679>; Fri, 18 Oct 1991 07:10:17 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11670>; Fri, 18 Oct 1991 07:07:48 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 18 Oct 1991 07:06:14 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11681>; Fri, 18 Oct 1991 07:05:56 -0700
Received: from TAUNIVM.TAU.AC.IL ([132.66.32.4]) by alpha.xerox.com with SMTP id <11678>; Fri, 18 Oct 1991 07:05:15 -0700
Received: from ccsg.tau.ac.il by TAUNIVM.TAU.AC.IL (IBM VM SMTP R1.2.2MX) with TCP; Fri, 18 Oct 91 16:04:47 IST
X-Mailer: ELM [version 2.3 PL11]
X-Ns-Transport-Id: 08002008D0FD0012139D
Xns-Originator: parc.xerox.com.PARC@Xerox.com
Errors-To: parc.xerox.com.PARC@xerox.com
In-Reply-To: "<9110171924.AA22915@sonne>; from \"Clay Luther\" at Oct 17, 91 12:24 pm"
Message-Id: <9110181354.AA00830@ccsg.tau.ac.il>
Date: 	Fri, 18 Oct 1991 06:54:43 -0700
From: Dov Samet <samet@ccsg.tau.ac.il>
Sender: <@taunivm.tau.ac.il:samet@ccsg.tau.ac.IL>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
Cc: moo-cows.PARC@xerox.com
Subject: Re: @notedit fails to edit description

The answe is very simple. It happens many times.
The @noteditor is wants a list as edting text, but you give it a string.
What you have to do is simply. before using the editor tpye:
;#2.description = {}
That'll do.

ZigZag


From crew@neon.stanford.edu Fri Oct 18 10:12:07 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <crew@neon.stanford.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA29600; Fri, 18 Oct 91 10:12:04 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11700>; Fri, 18 Oct 1991 10:11:21 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11719>; Fri, 18 Oct 1991 10:08:25 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 18 Oct 1991 10:06:19 -0700
Received: from Neon.Stanford.EDU ([36.28.0.92]) by alpha.xerox.com with SMTP id <11697>; Fri, 18 Oct 1991 10:05:55 -0700
Received: from LOCALHOST by Neon.Stanford.EDU with SMTP (5.61/25-eef) id AA17440; Fri, 18 Oct 91 10:05:53 -0700
X-Date: Fri, 18 Oct 91 10:00:44 PST
X-Ns-Transport-Id: 08002008D0FD001215C7
In-Reply-To: "Your message of Thu, 17 Oct 91 13:01:45 -0700.
             <9110172001.AA23699@boston-harbor>"
Message-Id: <9110181705.AA17440@Neon.Stanford.EDU>
Date: 	Fri, 18 Oct 1991 10:05:52 -0700
From: Roger Crew <crew@neon.stanford.edu>
To: moo-cows@parc.xerox.com
Subject: Re: @notedit fails to edit description

>     Now editing "yduJ"(#68).description.  [string mode]
>
>   I wonder if Rog added that after the August 26 Core was created.

to be sure.  I figure it was sometime within the last month.
There's also a `mode' command...
--
Roger Crew                                        ``I kill Optimax...''
Usenet:    {arpa gateways, decwrl, uunet, rutgers}!cs.stanford.edu!crew
Internet:  crew@CS.Stanford.EDU
MOO:       Rog

From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Fri Oct 18 11:12:52 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB00137; Fri, 18 Oct 91 11:12:50 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11807>; Fri, 18 Oct 1991 11:11:58 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11715>; Fri, 18 Oct 1991 11:10:25 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 18 Oct 1991 11:08:06 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11804>; Fri, 18 Oct 1991 11:07:31 -0700
Received: by sonne (4.1/1.36)
	id AA24590; Fri, 18 Oct 91 13:07:28 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0012171C
Message-Id: <9110181807.AA24590@sonne>
Date: 	Fri, 18 Oct 1991 11:07:28 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: NPC's

I have just recently started looking at Waffle's eliza object in Lambda.

I have been trying to figure out how to design "smart" npc's and creatures
using Moo.  For instance, I would like to develop smart bartenders or "robots"
that respond to the players actions, perhaps telling them important
information or whatever.

Besides eliza, has anyone else worked up something similar, or at least
prototypical, of what I am describing?  I am not really talking about puppets,
though.

Thanks.

-- 
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               Ignorance & Fear.  Fear & Ignorance.

From seth@alchemy.tn.cornell.edu Fri Oct 18 11:20:49 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <seth@alchemy.tn.cornell.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA00165; Fri, 18 Oct 91 11:20:47 PDT
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11789>; Fri, 18 Oct 1991 11:20:04 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11796>; Fri, 18 Oct 1991 11:18:49 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 18 Oct 1991 11:17:49 -0700
Received: from alchemy.tn.cornell.edu ([128.84.253.9]) by alpha.xerox.com with SMTP id <11795>; Fri, 18 Oct 1991 11:17:13 -0700
Received: by alchemy.tn.cornell.edu (4.1/SMI-4.1)
	id AA02991; Fri, 18 Oct 91 14:19:17 EDT
X-Ns-Transport-Id: 08002008D0FD0012173F
Message-Id: <9110181819.AA02991@alchemy.tn.cornell.edu>
Date: 	Fri, 18 Oct 1991 11:19:17 -0700
From: seth@alchemy.tn.cornell.edu (Seth Cohn)
To: moo-cows@parc.xerox.com
Subject: Robots


Yes, I was (am?  been busy)  working on a AI for the MOO scene.  Got a few ideas
but nothing major yet..
AlchemyMOO has been quite dead lately, since the dozen or so people who
were working on it have all been busy, off the net, or otherwise occupied.
I hope to continue working on it soon.  If anyone would like to join the
project, lemme know... Alchemy Needs Programmers!
                       (Mars)         (Women) :)
Seth

From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Fri Oct 18 13:56:46 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA00616; Fri, 18 Oct 91 13:56:43 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11861>; Fri, 18 Oct 1991 13:55:56 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11845>; Fri, 18 Oct 1991 13:53:26 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 18 Oct 1991 13:49:51 -0700
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11819>; Fri, 18 Oct 1991 13:49:43 -0700
Received: by sonne (4.1/1.36)
	id AA24828; Fri, 18 Oct 91 15:49:39 CDT
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0012198B
Message-Id: <9110182049.AA24828@sonne>
Date: 	Fri, 18 Oct 1991 13:49:38 -0700
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: printf()??

Is there a simple printf() or sprintf() like function in the Core?
I looked in string_utils, but no luck...

Reason:  I have a list of 15 numbers I would like to print in a single row,
all lined up properly under a list of headings.

ala

Head1  Head2  Head3  Head4
nn     nnnn   n      nnn


-- 
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               Ignorance & Fear.  Fear & Ignorance.

From yduj@lucid.com Fri Oct 18 14:08:56 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA00653; Fri, 18 Oct 91 14:08:54 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12000>; Fri, 18 Oct 1991 14:07:46 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11861>; Fri, 18 Oct 1991 14:03:58 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Fri, 18 Oct 1991 14:02:46 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11821>; Fri, 18 Oct 1991 14:02:22 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11951>; Fri, 18 Oct 1991 14:01:31 -0700
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA01631g; Fri, 18 Oct 91 14:00:54 PDT
Received: by boston-harbor id AA27195g; Fri, 18 Oct 91 17:02:14 EDT
X-Ns-Transport-Id: 08002008D0FD001219B6
In-Reply-To: "Clay Luther's message of Fri, 18 Oct 1991 13:49:38 -0700 <9110182049.AA24828@sonne>"
Message-Id: <9110182102.AA27195@boston-harbor>
Date: 	Fri, 18 Oct 1991 14:02:14 -0700
From: Judy Anderson <yduj@lucid.com>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu
Cc: moo-cows.PARC@xerox.com
Subject: printf()??

The short answer is that tostr() takes an arbitrary number of
arguments and coerces them to a string.  Player:tell and friends use
tostr before doing any output.  $string_utils:right, left, and center
may also be helpful.

player:tell($string_utils:right(foo[1],15)," & ",$string_utils:right(foo[2],10))

will print the items in the two element list in 15 and 10 column
fields, respectively, separated by "&".  I may have the string and
field size arguments to $string_utils:right backwards.  Try help
$string_utils and help $string_utils:right.
						yduJ



From yduj@lucid.com Mon Oct 21 20:47:59 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05385; Mon, 21 Oct 91 20:47:57 PDT
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11705>; Mon, 21 Oct 1991 20:47:05 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11690>; Mon, 21 Oct 1991 20:45:23 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Mon, 21 Oct 1991 20:42:51 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11698>; Mon, 21 Oct 1991 20:42:24 -0700
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11677>; Mon, 21 Oct 1991 20:41:34 -0700
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA03465g; Mon, 21 Oct 91 20:40:53 PDT
Received: by boston-harbor id AA05916g; Mon, 21 Oct 91 23:41:27 EDT
X-Ns-Transport-Id: 08002008D0FD001245E8
Message-Id: <9110220341.AA05916@boston-harbor>
Date: 	Mon, 21 Oct 1991 20:41:27 -0700
From: Judy Anderson <yduj@lucid.com>
To: moo-cows.PARC@xerox.com
Subject: Human Nature and the impact on MOO


LambdaMOO has been having what I call "asshole trouble" lately.  Most
of the problem connections come from the same site, which we can tell
through the connection log.  We don't particularly want to go full
registration, however, we are seeking some solution to the problem
other than the wizard always being on hand to @recycle the offender.

If the MOO had a primitive connection_name(player), where player could
be either a regular player object or one of these fake negative player
objects that connections are until they're connected, then
#0:do_login_command could refuse to automatically create new
characters from known troublemaking hosts, for example.

Pavel says that he doesn't have time to make such an improvement to
the server just now.  Are there any budding server hackers out there
who would be interested in taking on the task of creating this new
primitive?  I'm getting tired of recycling assholes.

Pavel's suggested semantics: connection_name(player) -> a string whose
form is network-specific but in our case is of the form `<number> from
<hostname>'.  (Oops, Pavel, I'm confused, what does <number>
represent?  Some port number or another?)

yduJ (Judy Anderson)        yduJ@lucid.com      'yduJ' rhymes with 'fudge'

From mg@bds.bds.com Tue Oct 22 01:16:23 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <mg@bds.bds.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05731; Tue, 22 Oct 91 01:16:16 PDT
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11738>; Tue, 22 Oct 1991 01:15:26 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11736>; Tue, 22 Oct 1991 01:12:53 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58370>; Tue, 22 Oct 1991 01:09:58 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11723>; Tue, 22 Oct 1991 01:09:25 -0700
Received: from bds.bds.com ([192.107.237.1]) by alpha.xerox.com with SMTP id <11735>; Tue, 22 Oct 1991 01:08:37 -0700
Received: by bds.bds.com (5.61/1.34)
	id AA19401; Tue, 22 Oct 91 04:08:15 -0400
X-Ns-Transport-Id: 08002008D0FD00124800
In-Reply-To: "Your message of Mon, 21 Oct 1991 20:41:27 -0700"
Message-Id: <CMM-RU.1.0.688118894.mg@bds>
Date: 	Tue, 22 Oct 1991 01:08:14 -0700
From: Mike Gallaher <mg@bds.bds.com>
To: Judy Anderson <yduj@lucid.com>
Cc: moo-cows.PARC@xerox.com
Subject: Re: Human Nature and the impact on MOO

Thanks for the excuse to do some server hacking.  It's my first attempt
but it seems to work.  Pavel, my compliments on some of the cleanest and
easiest-to-understand C code that I've worked with.  If only the code
I'm paid to work on was that good...

This patch adds the function connection_name(player) to the server.
It returns a string of the form '<number> from <hostname>',
which is the same format that appears in the connection log.
(<number> is the file descriptor of the connected socket, which
isn't terribly useful here.)
Only wizards can ask about players other than themselves; everyone
else gets E_PERM if they try.

*** bf_player.c-	Fri Aug  9 14:40:41 1991
--- bf_player.c	Tue Oct 22 03:34:48 1991
***************
*** 4,6 ****
  #include "server.h" 
! /* notify, connected_players, idle_seconds, connected_second, boot_player */
  
--- 4,8 ----
  #include "server.h" 
! /* notify, connected_players, idle_seconds, connected_second, boot_player,
!  * connection_name
!  */
  
***************
*** 77,79 ****
--- 79,103 ----
  
+ /* +++ MG 22-Oct-91 */
  static package
+   bf_connection_name(Var arglist, Byte next, void *vdata, Parse_Info *pi)
+ { /* (player) */
+   Var r;
+   extern char *player_connection_name();
+ 
+   if (!is_wizard(pi->progr) && pi->progr != arglist.v.list[1].v.obj) {
+     free_var(arglist);
+     return make_error_pack(E_PERM);
+   } 
+ 
+   r.type = TYPE_STR;
+   r.v.str = player_connection_name(arglist.v.list[1].v.obj);
+   free_var(arglist);
+   if (r.v.str == NULL)
+     return make_error_pack(E_INVARG);
+   else 
+     return make_var_pack(r);
+ }
+ /* --- MG 22-Oct-91 */
+ 
+ static package
    bf_set_player_flag(Var arglist, Byte next, void *vdata, Parse_Info *pi) 
***************
*** 139,140 ****
--- 163,168 ----
      = {"notify", 2, 2, {TYPE_OBJ, TYPE_STR}, bf_notify};
+ /* +++ MG 22-Oct-91 */
+   static struct bft_entry bft9 
+     = {"connection_name", 1, 1, {TYPE_OBJ}, bf_connection_name};
+ /* --- MG 22-Oct-91 */
  
***************
*** 148,149 ****
--- 176,178 ----
    register_function(bft8);
+   register_function(bft9);	/* MG 22-Oct-91 */
  }
*** server.c-	Tue Oct 22 03:04:15 1991
--- server.c	Tue Oct 22 03:19:51 1991
***************
*** 512,513 ****
--- 512,528 ----
  
+ /* +++ MG 22-Oct-91 */
+ char *
+ player_connection_name(Objid player)
+ {
+     shandle    *h = find_shandle(player);
+ 
+     if (h) {
+ 	char *n = network_connection_name (h->nhandle);
+ 
+ 	return n ? strdup (n) : NULL;
+     } else
+ 	return NULL;
+ }
+ /* --- MG 22-Oct-91 */
+ 
  int

From parc.xerox.com.PARC@xerox.com Tue Oct 22 05:45:50 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com.PARC@xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05912; Tue, 22 Oct 91 05:45:49 PDT
Errors-To: parc.xerox.com.PARC@xerox.com
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11779>; Tue, 22 Oct 1991 05:44:40 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11766>; Tue, 22 Oct 1991 05:43:04 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 22 Oct 1991 05:40:21 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11766>; Tue, 22 Oct 1991 05:39:57 -0700
Received: from po5.andrew.cmu.edu ([128.2.10.105]) by alpha.xerox.com with SMTP id <11773>; Tue, 22 Oct 1991 05:39:14 -0700
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA02607> for moo-cows.PARC@xerox.com; Tue, 22 Oct 91 08:39:05 EDT
Received: via switchmail; Tue, 22 Oct 1991 08:39:03 -0400 (EDT)
Received: from ccon.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.Ed11iS200Vo9Q0XEBS>;
          Tue, 22 Oct 1991 08:37:50 -0400 (EDT)
Received: from ccon.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr24/jb7w/.Outgoing/QF.sd11iHK00Vo9QiEWcz>;
          Tue, 22 Oct 1991 08:37:39 -0400 (EDT)
Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.ccon.weh.andrew.cmu.edu.pmax.ul4
          via MS.5.6.ccon.weh.andrew.cmu.edu.pmax_ul4;
          Tue, 22 Oct 1991 08:37:39 -0400 (EDT)
X-Ns-Transport-Id: 08002008D0FD0012493A
Xns-Originator: parc.xerox.com.PARC@Xerox.com
Errors-To: parc.xerox.com.PARC@xerox.com
In-Reply-To: <9110220341.AA05916@boston-harbor>
Message-Id: <Id11iH_00Vo9IiEWVX@andrew.cmu.edu>
References: <9110220341.AA05916@boston-harbor>
Date: 	Tue, 22 Oct 1991 05:37:39 -0700
From: Joseph Gerard Behrmann <jb7w+@andrew.cmu.edu>
Sender: <@po5.andrew.cmu.edu:jb7w+@andrew.cmu.EDU>
To: moo-cows.PARC@xerox.com
Subject: Re: Human Nature and the impact on MOO


I was thinking of that very primitive for the server, at the time I
thought of it I didn't wish to start playing with the server too much,
but if need be I'll hack it into the server and send Pavel the mods.
Is there enough interest in this sort of mod?


EVERYTHING NOT FORBIDDEN IS COMPULSORY - A little ant
"All that we see or seem is but a dream within a dream." - E.A.P.
						Joe
						jb7w+@andrew.cmu.edu

From parc.xerox.com.PARC@xerox.com Tue Oct 22 05:47:19 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <parc.xerox.com.PARC@xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA05917; Tue, 22 Oct 91 05:47:17 PDT
Errors-To: parc.xerox.com.PARC@xerox.com
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11742>; Tue, 22 Oct 1991 05:46:20 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11749>; Tue, 22 Oct 1991 05:45:14 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 22 Oct 1991 05:43:24 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11742>; Tue, 22 Oct 1991 05:42:59 -0700
Received: from po3.andrew.cmu.edu ([128.2.12.31]) by alpha.xerox.com with SMTP id <11772>; Tue, 22 Oct 1991 05:41:46 -0700
Received: by po3.andrew.cmu.edu (5.54/3.15) id <AA01602> for moo-cows.PARC@xerox.com; Tue, 22 Oct 91 08:41:35 EDT
Received: via switchmail; Tue, 22 Oct 1991 08:41:33 -0400 (EDT)
Received: from ccon.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.0d11kSu00Vo9E0XEFq>;
          Tue, 22 Oct 1991 08:39:59 -0400 (EDT)
Received: from ccon.weh.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr24/jb7w/.Outgoing/QF.Ad11kOW00Vo90iEXVl>;
          Tue, 22 Oct 1991 08:39:54 -0400 (EDT)
Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.ccon.weh.andrew.cmu.edu.pmax.ul4
          via MS.5.6.ccon.weh.andrew.cmu.edu.pmax_ul4;
          Tue, 22 Oct 1991 08:39:54 -0400 (EDT)
X-Ns-Transport-Id: 08002008D0FD0012493E
Xns-Originator: parc.xerox.com.PARC@Xerox.com
Errors-To: parc.xerox.com.PARC@xerox.com
In-Reply-To: <CMM-RU.1.0.688118894.mg@bds>
Message-Id: <Ud11kOO00Vo90iEXNZ@andrew.cmu.edu>
References: <CMM-RU.1.0.688118894.mg@bds>
Date: 	Tue, 22 Oct 1991 05:39:54 -0700
From: Joseph Gerard Behrmann <jb7w+@andrew.cmu.edu>
Sender: <@po3.andrew.cmu.edu:jb7w+@andrew.cmu.EDU>
To: moo-cows.PARC@xerox.com
Subject: Re: Human Nature and the impact on MOO

Oops, just received the actual patch seconds after I finished typing
in my post *sigh*, always seconds behind the times...

EVERYTHING NOT FORBIDDEN IS COMPULSORY - A little ant
"All that we see or seem is but a dream within a dream." - E.A.P.
						Joe
						jb7w+@andrew.cmu.edu

From pavel@parc.xerox.com Tue Oct 22 10:24:43 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA06666; Tue, 22 Oct 91 10:24:41 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11807>; Tue, 22 Oct 1991 10:23:34 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11785>; Tue, 22 Oct 1991 10:21:41 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Tue, 22 Oct 1991 10:20:41 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11761>; Tue, 22 Oct 1991 10:20:10 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11761>; Tue, 22 Oct 1991 10:19:20 -0700
Received: by lambda.parc.xerox.com id <58369>; Tue, 22 Oct 1991 10:19:09 -0700
X-Ns-Transport-Id: 08002008D0FD00124D24
In-Reply-To: <9110220341.AA05916@boston-harbor>
Message-Id: <91Oct22.101909pdt.58369@lambda.parc.xerox.com>
Date: 	Tue, 22 Oct 1991 10:19:00 -0700
From: Pavel Curtis <pavel@parc.xerox.com>
To: yduj@lucid.com
Cc: moo-cows.PARC@xerox.com
Subject: Re: Human Nature and the impact on MOO

Judy Anderson writes:
> Pavel says that he doesn't have time to make such an improvement to
> the server just now.  Are there any budding server hackers out there
> who would be interested in taking on the task of creating this new
> primitive?  I'm getting tired of recycling assholes.

If you do implement this primitive, please send me context diffs with the
changes and I'll add it into the server running here (and release them, too).

> Pavel's suggested semantics: connection_name(player) -> a string whose
> form is network-specific but in our case is of the form `<number> from
> <hostname>'.  (Oops, Pavel, I'm confused, what does <number>
> represent?  Some port number or another?)

It's not a very interesting number; it's the file descriptor of the server's
connection to that player.

	Pavel

From seth@alchemy.tn.cornell.edu Tue Oct 22 10:38:22 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <seth@alchemy.tn.cornell.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA06736; Tue, 22 Oct 91 10:38:19 PDT
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11802>; Tue, 22 Oct 1991 10:37:29 -0700
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11792>; Tue, 22 Oct 1991 10:36:03 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58369>; Tue, 22 Oct 1991 10:35:23 -0700
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11809>; Tue, 22 Oct 1991 10:34:48 -0700
Received: from alchemy.tn.cornell.edu ([128.84.253.9]) by alpha.xerox.com with SMTP id <11864>; Tue, 22 Oct 1991 10:28:51 -0700
Received: by alchemy.tn.cornell.edu (4.1/SMI-4.1)
	id AA01786; Tue, 22 Oct 91 13:28:43 EDT
X-Ns-Transport-Id: 08002008D0FD00124D53
Message-Id: <9110221728.AA01786@alchemy.tn.cornell.edu>
Date: 	Tue, 22 Oct 1991 10:28:43 -0700
From: seth@alchemy.tn.cornell.edu (Seth Cohn)
To: moo-cows.PARC@xerox.com
Subject: AlchemyMoo

Well, since someone actually mail me and said:
"Would be nice if you added the Alchemy address to your plea for people."

I talked it over with Matthew (the guy who owns the Sun (now a 3/140!!)
that the MOO runs on.. and since it's otherwise been dead, we agreed to make
it public.  That way, when it gets real busy and fun, THEN he can say it takes
too much space/memory and he'll kill. ;)

so:  Announcing AlchemyMOO goes public!!

Address: 128.84.253.9 1234
or       alchemy.tn.cornell.edu 1234

Theme: Surrealism (as weird as possible, then weirder)

Wizards: Sethus (that's me)
         waffle (that's him)
     and Matthew (the other guy)

It's bare, it's got flair, and it's there!

Seth


From cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu Sat Nov  2 14:19:13 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA00332; Sat, 2 Nov 91 14:19:09 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11858>; Sat, 2 Nov 1991 14:18:04 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11710>; Sat, 2 Nov 1991 14:12:42 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 2 Nov 1991 14:10:02 -0800
Received: from sonne ([129.120.4.5]) by alpha.xerox.com with SMTP id <11858>; Sat, 2 Nov 1991 14:09:43 PST
Received: by sonne (4.1/1.36)
	id AA21993; Sat, 2 Nov 91 16:09:29 CST
X-Mailer: ELM [version 2.3 PL8]
X-Ns-Transport-Id: 08002008D0FD0012E625
Message-Id: <9111022209.AA21993@sonne>
Date: 	Sat, 2 Nov 1991 14:09:29 PST
From: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com (Moo Cows)
Subject: Problems getting a match

I am having problems getting a verb argument to match an object.

The Straight Dope:

@add-partner any to this
(defined on $generic_bbs)

all_bbs = $object_utils:descendants($generic_bbs);
bbs = $match_utils:match(args[1],all_bbs);

????

For instance,

@add-partner "Jacob's BBS" to "Bob's BBS"

will not find "Jacob's BBS" (object #249).

I have also tried, for kicks, $string_utils:match_object(args[1],all_bbs);

Of course,

@add-partner #249 to "Bob's BBS"

works.

-- 
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               Ignorance & Fear.  Fear & Ignorance.

From yduj@lucid.com Sat Nov  2 14:45:34 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA00341; Sat, 2 Nov 91 14:45:31 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11861>; Sat, 2 Nov 1991 14:44:27 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11860>; Sat, 2 Nov 1991 14:41:14 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 2 Nov 1991 14:38:46 -0800
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11860>; Sat, 2 Nov 1991 14:38:27 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11860>; Sat, 2 Nov 1991 14:37:55 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA11565g; Sat, 2 Nov 91 14:36:47 PST
Received: by boston-harbor id AA01711g; Sat, 2 Nov 91 17:37:46 EST
X-Ns-Transport-Id: 08002008D0FD0012E644
In-Reply-To: "Clay Luther's message of Sat, 2 Nov 1991 14:09:29 PST <9111022209.AA21993@sonne>"
Message-Id: <9111022237.AA01711@boston-harbor>
Date: 	Sat, 2 Nov 1991 14:37:46 PST
From: Judy Anderson <yduj@lucid.com>
To: cluther%morticia.cnns.unt.edu@vaxb.acs.unt.edu
Cc: moo-cows.PARC@xerox.com
Subject: Problems getting a match

I think the "where" argument of $match_utils:match is intended to be
the room in which "what" might be found, not a list of possible
matches.  

Maybe you want
$string_utils:match(target_string,all_bbs,"name",all_bbs,"aliases")

Maybe certain unnamed parties could document $match_utils?

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

From cluther@morticia.cnns.unt.edu Mon Nov  4 09:33:21 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <cluther@morticia.cnns.unt.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA02172; Mon, 4 Nov 91 09:33:18 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11555>; Mon, 4 Nov 1991 09:31:53 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11566>; Mon, 4 Nov 1991 09:28:49 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 4 Nov 1991 09:24:37 -0800
Received: from morticia ([129.120.4.5]) by alpha.xerox.com with SMTP id <11600>; Mon, 4 Nov 1991 09:21:03 PST
Received: from [129.120.4.3] (gomez.cnns.unt.edu) by morticia (4.1/1.36)
	id AA24308; Mon, 4 Nov 91 11:20:07 CST
X-Ns-Transport-Id: 08002008D0FD0012F29F
Message-Id: <9111041720.AA24308@morticia>
Date: 	Mon, 4 Nov 1991 09:27:02 PST
From: cluther@morticia.cnns.unt.edu (Clay Luther)
To: moo-cows@parc.xerox.com
Subject: Is this legal?


Can a normal programmer do this:

1: settaskperms($wiz);

?
--
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               Ignorance & Fear.  Fear & Ignorance.


From weiler@cis.ohio-state.edu Mon Nov  4 10:12:14 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <weiler@cis.ohio-state.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA02243; Mon, 4 Nov 91 10:12:11 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11553>; Mon, 4 Nov 1991 10:10:46 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11576>; Mon, 4 Nov 1991 10:09:13 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 4 Nov 1991 10:07:02 -0800
Received: from hickory.cis.ohio-state.edu ([128.146.28.11]) by alpha.xerox.com with SMTP id <11577>; Mon, 4 Nov 1991 10:06:30 PST
Received: by hickory.cis.ohio-state.edu (5.61-kk/5.911008)
	id AA14646; Mon, 4 Nov 91 13:06:16 -0500
X-Mailer: ELM [version 2.3 PL0]
X-Ns-Transport-Id: 08002008D0FD0012F366
In-Reply-To: "<9111041720.AA24308@morticia>; from \"Clay Luther\" at Nov 4, 91 9:27 amare 3 bo"
Message-Id: <9111041806.AA14646@hickory.cis.ohio-state.edu>
Date: 	Mon, 4 Nov 1991 10:06:15 PST
From: Gerald Weiler <weiler@cis.ohio-state.edu>
To: moo-cows@parc.xerox.com
Subject: Re: Is this legal?

> Can a normal programmer do this:
> 
> 1: settaskperms($wiz);
> 
> ?

No, I believe only wizards can use settaskperms in the first place...

--
" Home is someplace you say 'My, this looks just like it did when I left'
  not 'My, this looks like six million dragons flew in and wrecked the
  joint!' " - Tasslehoff Burrfoot in DragonLance Legends
-------Gerald Weiler---(weiler@cis.ohio-state.edu)-----------------------

From yduj@lucid.com Mon Nov  4 14:27:03 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA02998; Mon, 4 Nov 91 14:27:00 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11653>; Mon, 4 Nov 1991 14:23:04 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11630>; Mon, 4 Nov 1991 14:20:00 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 4 Nov 1991 14:17:35 -0800
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11630>; Mon, 4 Nov 1991 14:17:24 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA01160g; Mon, 4 Nov 91 14:16:14 PST
Received: by boston-harbor id AA09528g; Mon, 4 Nov 91 17:17:17 EST
X-Ns-Transport-Id: 08002008D0FD0012F788
In-Reply-To: "Clay Luther's message of Mon, 4 Nov 1991 09:27:02 PST <9111041720.AA24308@morticia>"
Message-Id: <9111042217.AA09528@boston-harbor>
Date: 	Mon, 4 Nov 1991 14:17:17 PST
From: Judy Anderson <yduj@lucid.com>
To: cluther@morticia.cnns.unt.edu
Cc: moo-cows@parc.xerox.com
Subject: Is this legal?

A normal programmer cannot do set_task_perms at all, except to
themself.  Permission error, otherwise.  The MOO is pretty damn
secure...  $wiz is not an acceptable argument to set_task_perms,
because $wiz is (typically) not actually a player.
							yduJ

From pavel@parc.xerox.com Fri Nov  8 11:04:42 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA11663; Fri, 8 Nov 91 11:04:41 PST
Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <11781>; Fri, 8 Nov 1991 11:03:27 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11789>; Fri, 8 Nov 1991 10:54:31 PST
Received: by lambda.parc.xerox.com id <58371>; Fri, 8 Nov 1991 10:51:52 -0800
X-Ns-Transport-Id: 08002008D0FD00133177
Message-Id: <91Nov8.105152pst.58371@lambda.parc.xerox.com>
Date: 	Fri, 8 Nov 1991 10:51:41 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: New LambdaMOO server, version 1.5.0

[For some reason, the first version of this message just sat in my mail queue
 for three days and then expired.  I hope I have better luck this time...]

I have just released a new version of the LambdaMOO server for FTP from its
usual location:

	host: parcftp.xerox.com
	file: pub/MOO/LambdaMOO-1.5.0.tar.Z

The LambdaMOO Programmer's Manual has also been updated and is available for
FTP from the same directory.

Here's what the ChangeLog.txt file says about this release:

Version 1.5.0, 3 November 1991
-- Added connection_name(player) to allow wizards some level of reasonable
   control over whom they allow to connect to their servers.
-- Changed read() to accept an optional argument, player, specifying the player
   from whose connection to read.  If this argument is given, the check that
   the current task is an input task is not done.  The only good use for this
   that I'm aware of is in conjunction with the next change...
-- The new compilation option OUTBOUND_NETWORK enables a new built-in function
   called open_network_connection().  The arguments are specific to the network
   module in use, but the intent is that they somehow specify a remote place to
   which a network connection can be made.  For the default, BSD networking
   module, there are two arguments, a host-name string and a port number.  The
   function creates a connection to that place, if possible, and tricks the
   rest of the server into believing that a normal connection just came from
   that place.  Open_network_connection() returns the negative object number
   that is the pseudo-player object for that connection.  One can then use
   read() and notify() to send and receive lines of ASCII text on that
   connection.  Of course, if the server should ever receive a line of input
   when there's no task read()ing from the connection, that input will be
   treated as a command in the usual way.  Also, unless the connection `logs
   in' at some point, the usual five-minute timeout-if-no-input-received
   connection shutdown will take place.  The usual practice is to have the same
   task that opens the connection go into an infinite loop read()ing from it.
   As usual, boot_player() can be used to shut down the connection.  This
   function can only be called by wizards, of course.  If the OUTBOUND_NETWORK
   option is not used, then open_network_connection() still exists, but always
   raises E_PERM.
-- Changed the bsd_network module to map tab to space on input, rather than
   simply dropping tabs on the floor.

From doug@cc.ysu.edu Sun Nov 10 23:05:33 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <doug@cc.ysu.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14434; Sun, 10 Nov 91 23:05:30 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11980>; Sun, 10 Nov 1991 23:04:04 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11984>; Sun, 10 Nov 1991 22:59:34 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sun, 10 Nov 1991 22:54:24 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11980>; Sun, 10 Nov 1991 22:54:03 PST
Received: from unix1.cc.ysu.edu ([192.55.234.50]) by alpha.xerox.com with SMTP id <11980>; Sun, 10 Nov 1991 22:53:29 PST
Received: by unix1.cc.ysu.edu (AIX 3.1/UCB 5.61/91.080817a)
          id AA10373; Mon, 11 Nov 91 01:50:46 -0500
Organization: Youngstown State University
X-Mailer: ELM [version 2.3 PL11]
X-Ns-Transport-Id: 08002008D0FD00134505
Message-Id: <9111110650.AA10373@unix1.cc.ysu.edu>
Date: 	Sun, 10 Nov 1991 22:50:46 PST
From: doug@cc.ysu.edu (Doug Sewell)
To: MOO-cows.PARC@xerox.com
Subject: RS6000

I brought up a moo on an IBM RS6000, after making these changes:

The moo-provided malloc does not work, and the -DFIND_LEAKS is actually
a work-around because the RS6000 doesn't like 0-sized mallocs, and
moo does one somewhere, causing a panic-msg.

In Makefile:

DEFS = -DUSE_RANDOM -DUSE_POSIX -DUSE_SYSTEM_MALLOC -DRS6000 -DFIND_LEAKS
CC = cc
OPTFLAGS = -g -O
CFLAGS = $(OPTFLAGS) $(DEFS)

Add these lines to the end of my-sys-time.h:

#ifdef RS6000
#include <sys/select.h>
#endif

With these changes, it compiled clean.

I ftp'd the lambdacore DB.  It starts fine (I was surprised it doesn't
automatically daemonize itself....)         

I telneted to the port, got the 'sign on as wizard' message, entered
'connect wizard', and nothing happened.  Is this normal ?  Should I
get some greeting after 'connect' ?  If I enter 'look me', nothing.
Likewise for 'describe me as'.

(Serves me right for jumping into this headlong.... but I have an
idea in mind that moo is probably the ideal choice for, of all the
alternatives.  I can't do what I want on an Untermud, which we've
got running now).  Well, now, off to Lambda House for a bit...

Doug

From pavel@parc.xerox.com Tue Nov 12 13:50:24 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB02335; Tue, 12 Nov 91 13:50:23 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11804>; Tue, 12 Nov 1991 13:49:58 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11795>; Tue, 12 Nov 1991 13:47:26 PST
Received: by lambda.parc.xerox.com id <58371>; Tue, 12 Nov 1991 13:44:24 -0800
X-Ns-Transport-Id: 08002008D0FD00135A97
Message-Id: <91Nov12.134424pst.58371@lambda.parc.xerox.com>
Date: 	Tue, 12 Nov 1991 13:44:15 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: New LambdaMOO server minor release, v. 1.5.1

I have incorporated a version of Doug's changes to make the server work under
IBM RS/6000 AIX, including a fix for the problem he was having with the server
being unresponsive.  These changes are part of a new minor release of the
server, version 1.5.1, now available for FTP from

	[parcftp.xerox.com]/pub/MOO/LambdaMOO-1.5.1.tar.Z

Here's what the ChangeLog has to say:

Version 1.5.1, 12 November 1991
-- Fixed bug in checkpointing whereby the server's command log was flushed even
   if the checkpoint failed.
-- Various minor tweaks to make the server work on an IBM RS/6000.


	Pavel/Haakon

From rsoft!mindlink!Frank@wimsey.bc.ca Sat Nov 16 17:12:40 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <rsoft!mindlink!Frank@wimsey.bc.ca>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA12561; Sat, 16 Nov 91 17:12:39 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11883>; Sat, 16 Nov 1991 17:09:37 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11884>; Sat, 16 Nov 1991 17:02:49 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 16 Nov 1991 17:00:12 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11880>; Sat, 16 Nov 1991 16:59:36 PST
Received: from wimsey.bc.ca ([192.48.234.1]) by alpha.xerox.com with SMTP id <11880>; Sat, 16 Nov 1991 16:59:10 PST
Received: by wimsey.bc.ca (/\==/\ Smail3.1.22.1 #22.7 rmail)
	id <m0kiaov-0000gzC@wimsey.bc.ca>; Sat, 16 Nov 91 16:57 PST
Received: by rsoft.bc.ca (/\==/\ Smail3.1.20.1 #20.26 rmail)
	id <m0kiZuS-00027XC@rsoft.bc.ca>; Sat, 16 Nov 91 15:58 PST
X-Ns-Transport-Id: 08002008D0FD0013A50D
Message-Id: <m0kiZuS-00027XC@rsoft.bc.ca>
Date: 	Sat, 16 Nov 1991 15:58:00 PST
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Sender: rsoft!mindlink!Frank@wimsey.bc.ca
To: MOO-Cows.PARC@xerox.com
Subject: Beginner's questions

We've just begun setting up a MOO in B.C. (is this Canada's first?) and playing
around on Lamda.  This message may be the first of a few asking amateurish
questions.  I hope you'll bear with us.

Amateur question #1:

Why does MOO not support the BACKSPACE key?  I feel I must be overlooking
something obvious; with all the excellent features that persuaded me to make
our mud a moo I am amazed by this simple but constantly frustrating quirk.

Frank.
--
___________________________________________________________________
Frank I. Reiter                UUCP:  ...!van-bc!rsoft!frank
Reiter Software Inc.       INTERNET: frank@mindlink.bc.ca (prefered)
Surrey, British Columbia             frank@rsoft.bc.ca

From nr@princeton.edu Sat Nov 16 17:28:46 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <nr@princeton.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA12575; Sat, 16 Nov 91 17:28:45 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11890>; Sat, 16 Nov 1991 17:26:20 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11888>; Sat, 16 Nov 1991 17:24:40 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 16 Nov 1991 17:23:39 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11888>; Sat, 16 Nov 1991 17:23:19 PST
Received: from Princeton.EDU ([128.112.128.1]) by alpha.xerox.com with SMTP id <11889>; Sat, 16 Nov 1991 17:22:28 PST
Received: from fs.Princeton.EDU by Princeton.EDU (5.65b/2.84/princeton)
	id AA27713; Sat, 16 Nov 91 19:33:13 -0500
Received: from cs.Princeton.EDU (dynamic.Princeton.EDU) by fs.Princeton.EDU (4.0/1.105)
	id AA15552; Sat, 16 Nov 91 20:22:18 EST
Received: by cs.Princeton.EDU (5.57/1.105)
	id AA07434; Sat, 16 Nov 91 20:22:16 -0500
X-Ns-Transport-Id: 08002008D0FD0013A528
Message-Id: <9111170122.AA07434@cs.Princeton.EDU>
Date: 	Sat, 16 Nov 1991 17:22:16 PST
From: Norman Ramsey <nr@princeton.edu>
To: MOO-Cows.PARC@xerox.com
Subject: why no backspace on the moo?

> Why does MOO not support the BACKSPACE key?

As far as I understand, the MOO wizards suggest that we use an
interface program, like `tinytalk' the mud-mode on GNU emacs.
Such programs not only deal with backspaces but let you do all kinds
of editing, make sure that your input doesn't get mixed up with other
people's output, and so on.  I believe mud-mode can be ftp'ed from
parcftp.parc.xerox.com, but I don't remember just where.

Happy MOO-ing.


Norman
 

From yduj@lucid.com Sat Nov 16 18:53:06 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <yduj@lucid.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA12647; Sat, 16 Nov 91 18:53:05 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11887>; Sat, 16 Nov 1991 18:52:43 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11888>; Sat, 16 Nov 1991 18:50:55 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 16 Nov 1991 18:49:22 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11887>; Sat, 16 Nov 1991 18:49:03 PST
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11887>; Sat, 16 Nov 1991 18:48:31 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA11265g; Sat, 16 Nov 91 18:46:56 PST
Received: by boston-harbor id AA11017g; Sat, 16 Nov 91 21:48:33 EST
X-Ns-Transport-Id: 08002008D0FD0013A58E
In-Reply-To: "Norman Ramsey's message of Sat, 16 Nov 1991 17:22:16 PST <9111170122.AA07434@cs.Princeton.EDU>"
Message-Id: <9111170248.AA11017@boston-harbor>
Date: 	Sat, 16 Nov 1991 18:48:33 PST
From: Judy Anderson <yduj@lucid.com>
To: MOO-Cows.PARC@xerox.com
Subject: why no backspace on the moo?

mud.el can be ftp'd from parcftp.xerox.com, directory pub/MOO/clients/.

However, I suspect for a BBS-style mud, most users won't have gnuemacs
available :-)

>> Why does MOO not support the BACKSPACE key?

Basically, the reason that MOO doesn't support backspace is because
then you'd demand that it do something interesting with it.  On an IBM
3278 terminal.  On a VT100.  On an LA120.  Then you'd want to set your
backspace character to delete instead.  And so on.

But I'm confused: MOO doesn't echo your characters in the first place,
why do you need backspace?  You should be getting local echo from your
host, and if you can convince it to do your backspacing too, you're
set...

It's part of the mud philosophy to demand that the user's client be
responsible for interfacing to the mud to avoid precisely the above
worries.  Next you'll want to emote curses sequences and then
someone'll download VT100 softkey redefinitions on some poor
unsuspecting user and crack their machine through the MOO...

Possibly a very simple echo and backspace processor that echoed
"backspace space backspace" and removed the preceeding character from
the input stream would be a benefit to MOO, without adding gobs and
gobs of extraneous code.  Of course it would have to be configurable:
I'm very happy with my client and don't particularly want the MOO
doing any echoing for me!

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

From pavel@parc.xerox.com Sun Nov 17 13:55:45 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13307; Sun, 17 Nov 91 13:55:44 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11918>; Sun, 17 Nov 1991 13:55:06 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11921>; Sun, 17 Nov 1991 13:53:19 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sun, 17 Nov 1991 13:52:20 -0800
Received: from Charon.Parc.Xerox.xns by alpha.xerox.com via XNS id <11917>; Sun, 17 Nov 1991 13:52:06 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11920>; Sun, 17 Nov 1991 13:51:40 PST
Received: by lambda.parc.xerox.com id <58371>; Sun, 17 Nov 1991 13:51:34 -0800
X-Ns-Transport-Id: 08002008D0FD0013A8E1
In-Reply-To: <m0kiZuS-00027XC@rsoft.bc.ca>
Message-Id: <91Nov17.135134pst.58371@lambda.parc.xerox.com>
Date: 	Sun, 17 Nov 1991 13:51:29 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: Frank@mindlink.bc.ca
Cc: MOO-Cows.PARC@xerox.com
Subject: Re: Beginner's questions

> Why does MOO not support the BACKSPACE key?  I feel I must be overlooking
> something obvious; with all the excellent features that persuaded me to make
> our mud a moo I am amazed by this simple but constantly frustrating quirk.

LambdaMOO, like all other MUDs of which I'm aware, makes the assumption that
the `client' software (the stuff with which a user directly interacts) is
responsible for (a) all line-editing, (b) any formatting of server output,
including line-breaking, and (c) any necessary separation of the user's input
from the server's output.  It is assumed that client software can more easily
and effectively provide this level of support than could the server.

As a result, the MOO does not provide any of these features, including support
for a backspace character.

Most people connect to LambdaMOO using the `telnet' program provided by many
operating systems.  In most of these cases, such programs have the option of
operating in either character-at-a-time or line-at-a-time mode.  The latter
mode does local editing and line-editing, only sending complete lines to the
other end of the network connection.  Of course, these programs all have
different ways of specifying the mode desired.  On UNIX and in certain
Macintosh telnet programs, line-at-a-time mode is used automatically if a
specific destination port number is given.

Other mudders employ more specialized programs than telnet as their MUD
clients.  Long lists of available clients are posted regularly to
rec.games.mud; I strongly recommend their use by those who can.

I hope that answers the backspace question; please feel free to let me know if
you still have questions, though.

	Pavel

From micor!latour!mcr Mon Nov 18 00:26:14 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <micor!latour!mcr>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA13788; Mon, 18 Nov 91 00:26:13 PST
Received: from Toucan.Parc.Xerox.xns by alpha.xerox.com via XNS id <11522>; Mon, 18 Nov 1991 00:25:50 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11521>; Mon, 18 Nov 1991 00:13:46 PST
Received: by lambda.parc.xerox.com via suspension id <58372>; Mon, 18 Nov 1991 00:10:48 -0800
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 18 Nov 1991 00:03:00 -0800
Received: from bertrand.ccs.carleton.ca ([134.117.1.13]) by alpha.xerox.com with SMTP id <12612>; Mon, 18 Nov 1991 00:02:41 PST
Received: from micor.UUCP by bertrand.ccs.carleton.ca (4.1/SMI-4.0)
	id AA20342; Mon, 18 Nov 91 03:00:26 EST
Received: by micor.OCUnix.On.Ca (smail2.5)
	id AA29552; 18 Nov 91 01:52:28 EST (Mon)
Received: by Sandelman.OCUnix.On.Ca (4.1/smail2.5/91-02-17)
	id AA10231; Sun, 17 Nov 91 22:18:03 EST
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
X-Ns-Transport-Id: 08002008D0FD0013ACE0
In-Reply-To: "Frank@mindlink.bc.ca (Frank I. Reiter)
       \"Beginner's questions\" (Nov 16,  3:58pm)?  Cook,"
Message-Id: <9111180318.AA10231@Sandelman.OCUnix.On.Ca>
Date: 	Sun, 17 Nov 1991 19:17:59 PST
From: mcr@sandelman.ocunix.on.ca (Michael Richardson)
Sender: micor!latour!mcr
To: Frank@mindlink.bc.ca (Frank I. Reiter), moo-cows@parc.xerox.com
Subject: Re: Beginner's questions

On Nov 16,  3:58pm, Frank I. Reiter wrote:
} We've just begun setting up a MOO in B.C. (is this Canada's first?)

  Maybe. Mine isn't on the Internet.

} Why does MOO not support the BACKSPACE key?  I feel I must be overlooking
} something obvious; with all the excellent features that persuaded me to make
} our mud a moo I am amazed by this simple but constantly frustrating

  As far as I've ever been able to tell, MOO does not do any kind of
Telnet negotiation. This is unfortunate, as it can't then put the
connection in line-mode and not worry about backspace/DEL problems. 
  I think the other answer is that most people use MUD clients of some
kind. I know that I'd be lost without mud.el myself.




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




From rsoft!mindlink!Frank@wimsey.bc.ca Mon Nov 18 09:16:47 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <rsoft!mindlink!Frank@wimsey.bc.ca>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14313; Mon, 18 Nov 91 09:16:46 PST
Received: from Charon.Parc.Xerox.xns by alpha.xerox.com via XNS id <11569>; Mon, 18 Nov 1991 09:16:14 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11578>; Mon, 18 Nov 1991 09:09:48 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 18 Nov 1991 09:08:33 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11587>; Mon, 18 Nov 1991 09:08:10 PST
Received: from wimsey.bc.ca ([192.48.234.1]) by alpha.xerox.com with SMTP id <11575>; Mon, 18 Nov 1991 09:07:31 PST
Received: by wimsey.bc.ca (/\==/\ Smail3.1.22.1 #22.7 rmail)
	id <m0kjCR6-0001T5C@wimsey.bc.ca>; Mon, 18 Nov 91 09:07 PST
Received: by rsoft.bc.ca (/\==/\ Smail3.1.20.1 #20.26 rmail)
	id <m0kjCT6-0001qtC@rsoft.bc.ca>; Mon, 18 Nov 91 09:09 PST
X-Ns-Transport-Id: 08002008D0FD0013B08D
Message-Id: <m0kjCT6-0001qtC@rsoft.bc.ca>
Date: 	Mon, 18 Nov 1991 09:09:00 PST
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Sender: rsoft!mindlink!Frank@wimsey.bc.ca
To: MOO-Cows.PARC@xerox.com
Subject: Re: Beginner's questions

> pavel@parc.xerox.com writes:
> 
> Other mudders employ more specialized programs than telnet as their MUD
> clients.  Long lists of available clients are posted regularly to
> rec.games.mud; I strongly recommend their use by those who can.

The only one we have located thus far is for emacs, which we do not use.
Other trails have been dead ends (couldn't connect to host, connected but no
such files, etc.)

Pointers to a C language client gratefully accepted!

Frank.

--
___________________________________________________________________
Frank I. Reiter                UUCP:  ...!van-bc!rsoft!frank
Reiter Software Inc.       INTERNET: frank@mindlink.bc.ca (prefered)
Surrey, British Columbia             frank@rsoft.bc.ca

From rsoft!mindlink!Frank@wimsey.bc.ca Mon Nov 18 09:19:00 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <rsoft!mindlink!Frank@wimsey.bc.ca>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA14323; Mon, 18 Nov 91 09:19:00 PST
Received: from Charon.Parc.Xerox.xns by alpha.xerox.com via XNS id <11584>; Mon, 18 Nov 1991 09:18:35 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11590>; Mon, 18 Nov 1991 09:10:47 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 18 Nov 1991 09:09:53 -0800
Received: from Charon.Parc.Xerox.xns by alpha.xerox.com via XNS id <11575>; Mon, 18 Nov 1991 09:08:50 PST
Received: from wimsey.bc.ca ([192.48.234.1]) by alpha.xerox.com with SMTP id <11581>; Mon, 18 Nov 1991 09:08:01 PST
Received: by wimsey.bc.ca (/\==/\ Smail3.1.22.1 #22.7 rmail)
	id <m0kjCR5-0001UXC@wimsey.bc.ca>; Mon, 18 Nov 91 09:07 PST
Received: by rsoft.bc.ca (/\==/\ Smail3.1.20.1 #20.26 rmail)
	id <m0kjCOw-0003ZTC@rsoft.bc.ca>; Mon, 18 Nov 91 09:04 PST
X-Ns-Transport-Id: 08002008D0FD0013B08F
Message-Id: <m0kjCOw-0003ZTC@rsoft.bc.ca>
Date: 	Mon, 18 Nov 1991 09:04:00 PST
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Sender: rsoft!mindlink!Frank@wimsey.bc.ca
To: MOO-Cows.PARC@xerox.com
Subject: Re: why no backspace on the moo?

> yduj@lucid.com writes:
> 
> But I'm confused: MOO doesn't echo your characters in the first place,
> why do you need backspace?  You should be getting local echo from your
> host, and if you can convince it to do your backspacing too, you're
> set...

Another reader has found the source of my confusion:

On several other MUDs we've tried the mud software put TELNET into line at a
time mode during the connect negotiation and so backspace worked just fine
there.  With MOO I need only put telnet into that mode manually and voila, I
will have a backspace key again.

Thanks to all the folks who answered both here and in my mailbox!

BTW: I can report that the current release of MOO ports to SCO Unix in half a
day or so.

Frank.
--
___________________________________________________________________
Frank I. Reiter                UUCP:  ...!van-bc!rsoft!frank
Reiter Software Inc.       INTERNET: frank@mindlink.bc.ca (prefered)
Surrey, British Columbia             frank@rsoft.bc.ca

From davidsan@microsoft.com Tue Nov 26 11:23:58 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <davidsan@microsoft.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA06933; Tue, 26 Nov 91 11:23:57 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11903>; Tue, 26 Nov 1991 11:23:14 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11905>; Tue, 26 Nov 1991 11:19:36 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 26 Nov 1991 11:15:13 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11890>; Tue, 26 Nov 1991 11:14:29 PST
Received: from microsoft.COM ([131.107.1.2]) by alpha.xerox.com with SMTP id <11890>; Tue, 26 Nov 1991 11:13:46 PST
Received: from microsoft by ingate.microsoft.COM
	id aa08059; Tue, 26 Nov 91 11:14:42 PST
X-Ns-Transport-Id: 08002008D0FD00141C91
Message-Id: <9111261114.aa08059@ingate.microsoft.COM>
Date: 	Tue, 26 Nov 1991 09:20:28 PST
From: davidsan@microsoft.com
To: MOO-Cows.PARC@xerox.com
Subject: List operations that perform copies

Was curious about two things:
1) Does length(list) perform a copy of the list?
2) Does list[element] perform a copy?

Thanks!
  Dave Sanderman -- davidsan@microsoft.com


From pavel@parc.xerox.com Tue Nov 26 18:29:38 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA07942; Tue, 26 Nov 91 18:29:37 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11964>; Tue, 26 Nov 1991 18:28:55 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11961>; Tue, 26 Nov 1991 18:26:11 PST
Received: by lambda.parc.xerox.com id <58371>; Tue, 26 Nov 1991 18:24:37 -0800
X-Ns-Transport-Id: 08002008D0FD001422F2
In-Reply-To: <9111261114.aa08059@ingate.microsoft.COM>
Message-Id: <91Nov26.182437pst.58371@lambda.parc.xerox.com>
Date: 	Tue, 26 Nov 1991 18:24:28 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: davidsan@microsoft.com
Cc: MOO-Cows@parc.xerox.com
Subject: Re: List operations that perform copies

davidsan@microsoft.com writes:
> 1) Does length(list) perform a copy of the list?
> 2) Does list[element] perform a copy?

I'm not quite sure what these questions mean, so I'll answer them in both of
the two ways I can understand them.

>From the standpoint of MOO language semantics, all values are immutable, so you
can't tell whether or not a copy is being performed.

>From the standpoint of the actual implementation, there are lots and lots of
copies going on.  The problem is one of memory management; the server needs to
be sure that it frees any storage that it allocates exactly once.  To ensure
that, the current implementation carefully copies a MOO value whenever it makes
a second `reference' to it.  That way, whenever a reference is to be discarded,
we know that it's the only reference to that copy of the value, so that copy
can be freed immediately.  A more clever implementation would maintain within
each value a count of the references that exist to it.  Making new references
would then consist of simply bumping that count and discarding a reference is
accomplished by just decrementing the count.  When a decrement pushes the count
to zero, the value can be freed.

This is how some higher-level languages do automatic storage allocation (i.e.,
`garbage collection'), but it has pitfalls in most of those languages: if a
cycle of references gets created somehow (e.g., value A contains a reference to
value B and vice-versa), then even after all other references to the cycle are
discarded, the values will have non-zero counts, due to all of the other values
in the cycle.  This is not a problem in MOO, however, because MOO values are
immutable and cycles cannot be formed without value-mutation.

I have long had plans to change the server to use reference counting instead of
copying, but have not yet gotten around to it.  It would be quite a performance
boon, as it turns out; the vast majority of the time that the server spends
running MOO code is spent copying values.

To answer your questions more specifically, every variable reference copies the
value of the variable, so `length(list)' does indeed copy the list.  Also,
extracting an element from a list copies that element, so `list[index]' first
copies the list (because of the variable reference for `list') and then copies
the index'th element a second time during the indexing operation.  As I said
above, there's a whole lot of copying going on...

	Pavel/Haakon/Lambda

From davidsan@microsoft.com Wed Nov 27 21:21:03 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <davidsan@microsoft.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA10483; Wed, 27 Nov 91 21:21:03 PST
Received: from microsoft.COM ([131.107.1.2]) by alpha.xerox.com with SMTP id <12414>; Wed, 27 Nov 1991 21:20:18 PST
Received: from microsoft by ingate.microsoft.COM
	id aa01772; Wed, 27 Nov 91 21:21:16 PST
Message-Id: <9111272121.aa01772@ingate.microsoft.COM>
Date: 	Wed, 27 Nov 1991 08:20:48 PST
From: davidsan@microsoft.com
To: ingate!pavel@parc.xerox.com
Cc: moo-cows@parc.xerox.com
Subject: Re: List operations that perform copies

| To answer your questions more specifically, every variable reference copies the
| value of the variable, so `length(list)' does indeed copy the list.  Also,
| extracting an element from a list copies that element, so `list[index]' first
| copies the list (because of the variable reference for `list') and then copies
| the index'th element a second time during the indexing operation.  As I said
| above, there's a whole lot of copying going on...

Ok, this was the info I was after.  So for me to implement a 'fortune'
type feature, I could save one copy of the entire list by storing the
length separately (which I could do, since the number of fortunes won't
change often).  That's all I needed to know.  Thanks!


From nils@geom.umn.edu Sat Nov 30 09:32:21 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <nils@geom.umn.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA12053; Sat, 30 Nov 91 09:32:20 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11677>; Sat, 30 Nov 1991 09:31:32 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11694>; Sat, 30 Nov 1991 09:16:14 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sat, 30 Nov 1991 09:09:52 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11713>; Sat, 30 Nov 1991 09:09:31 PST
Received: from poincare.geom.umn.edu ([128.101.25.31]) by alpha.xerox.com with SMTP id <11694>; Sat, 30 Nov 1991 09:08:48 PST
Received: from euclid.geom.umn.edu by poincare.geom.umn.edu; Sat, 30 Nov 91 11:08:49 CST
Received: by euclid.geom.umn.edu; Sat, 30 Nov 91 11:08:49 CST
X-Ns-Transport-Id: 08002008D0FD00143E6A
Message-Id: <9111301708.AA10114@euclid.geom.umn.edu>
Date: 	Sat, 30 Nov 1991 09:08:49 PST
From: nils@geom.umn.edu
To: MOO-Cows.PARC@xerox.com
Subject: multiple inheritance?

i heard there was an idea on how multiple inheritence is gunna be
implemented... could the people who know about this please be
really nice and explain how it's gunna be done?

thanks!
-koosh


From nils@geom.umn.edu Sat Nov 30 18:03:06 1991
X-VM-Attributes: [nil nil nil nil nil]
Status: RO
Return-Path: <nils@geom.umn.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA12338; Sat, 30 Nov 91 18:03:05 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11852>; Sat, 30 Nov 1991 18:02:20 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11851>; Sat, 30 Nov 1991 18:00:04 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sat, 30 Nov 1991 17:56:59 -0800
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11852>; Sat, 30 Nov 1991 17:56:39 PST
Received: from poincare.geom.umn.edu ([128.101.25.31]) by alpha.xerox.com with SMTP id <11851>; Sat, 30 Nov 1991 17:56:05 PST
Received: from euclid.geom.umn.edu by poincare.geom.umn.edu; Sat, 30 Nov 91 19:56:10 CST
Received: by euclid.geom.umn.edu; Sat, 30 Nov 91 19:56:12 CST
X-Ns-Transport-Id: 08002008D0FD00144062
Message-Id: <9112010156.AA10423@euclid.geom.umn.edu>
Date: 	Sat, 30 Nov 1991 17:56:12 PST
From: nils@geom.umn.edu
To: MOO-Cows.PARC@xerox.com
Subject: local catching of errors?

don't you just hate it if you want to catch an error, such as E_PERM,
but when you do, you don't get told about other errors? well, how
about we all do this:

catch ({E_PERM, E_INVARG})
  "do stuff in which E_PERM and E_INVARG don't abort";
endcatch

or,

catch ({E_PERM, E_INVARG}) in foovar
  "do stuff in which E_PERM and E_INVARG might occur.";
whencaught
  player:tell("Got a ", tostr(foovar), " error.");
endcatch

how about it?


From pavel@parc.xerox.com Mon Dec  2 17:01:13 1991
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB14753; Mon, 2 Dec 91 17:01:13 PST
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11679>; Mon, 2 Dec 1991 17:00:22 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11662>; Mon, 2 Dec 1991 16:56:23 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 2 Dec 1991 16:50:56 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11685>; Mon, 2 Dec 1991 16:50:14 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11668>; Mon, 2 Dec 1991 16:48:14 PST
Received: by lambda.parc.xerox.com id <58373>; Mon, 2 Dec 1991 16:47:39 -0800
X-Ns-Transport-Id: 08002008D0FD00145026
In-Reply-To: <9112010156.AA10423@euclid.geom.umn.edu>
Message-Id: <91Dec2.164739pst.58373@lambda.parc.xerox.com>
Date: 	Mon, 2 Dec 1991 16:47:31 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: nils@geom.umn.edu
Cc: MOO-Cows.PARC@xerox.com
Subject: Re: local catching of errors?

A few months ago I proposed a couple of new MOO constructs for raising and
catching errors, but I don't remember getting any comments on them.  Here's the
original description:

I have been considering for some time adding the statement

	RAISE expression;

and the expression

	` expression '

to the language to allow MOO programs to raise and handle errors.  The idea is
that the RAISE statement is kind of like RETURN except that the value of the
given expression is raised as an error, not simply returned to the verb's
caller.  The quoted expression shown above would server for catching errors
raised either by the RAISE statement or by primitive functions and other
constructs of the language (e.g., type errors, division by zero, etc.).  The
idea is that the expression

	` e '

evaluates e as usual and, if no error is raised during that evaluation, simply
returns the resulting value.  If, however, evaluation of e causes an error to
be raised, that error value would immediately be returned from the quoted
expression and execution would continue as before.

Thus, for example, one could safely say

	if (typeof(`z:foo()') == ERR)
	  ... recover from the error ...
	endif

assuming that z:foo() never returns an error value.  If you had no guarantee as
to what kind of value it might return, you could still detect whether or not an
error had occurred as follows:

	x = 1; y = 0;
	x = `y = z:foo()';
	if (x != y)
	  ... recover from the error ...
	endif

This sort of dancing should rarely be necessary, however.

In any case, I think that this sort of more local control over error-handling
or any other such matter, including supression of suspending, is a better
approach than verb-wide scoping.

From nils@geom.umn.edu Tue Dec  3 13:59:22 1991
Return-Path: <nils@geom.umn.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA17060; Tue, 3 Dec 91 13:59:21 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11754>; Tue, 3 Dec 1991 13:58:18 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11955>; Tue, 3 Dec 1991 13:53:04 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 3 Dec 1991 13:49:51 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11966>; Tue, 3 Dec 1991 13:49:07 PST
Received: from poincare.geom.umn.edu ([128.101.25.31]) by alpha.xerox.com with SMTP id <11963>; Tue, 3 Dec 1991 13:48:17 PST
Received: from euclid.geom.umn.edu by poincare.geom.umn.edu; Tue, 3 Dec 91 15:48:23 CST
Received: by euclid.geom.umn.edu; Tue, 3 Dec 91 15:48:23 CST
X-Ns-Transport-Id: 08002008D0FD00145CA5
Message-Id: <9112032148.AA12649@euclid.geom.umn.edu>
Date: 	Tue, 3 Dec 1991 13:48:23 PST
From: nils@geom.umn.edu
To: MOO-Cows.PARC@xerox.com
Subject: in-server verb processing?

how about.. in server verb processing? like have a
#0:do_commmand(player,command) or possibly a player:run_command(command)?
yes i know this was talked about a long time ago, but i gotta new reason:
then we can have custom verb info! yay!
like define our own predicate syntax, etc. so verb infos wouldn't just
be a 3 element list of all strings, they could be anything you possibly
want them to be, and so you could customize your predicate list without
changing the server or anything! (one less reason to make a server mod!
yay!)

maybe?
-koosh


From nils@geom.umn.edu Tue Dec  3 14:09:08 1991
Return-Path: <nils@geom.umn.edu>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA17080; Tue, 3 Dec 91 14:09:07 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11662>; Tue, 3 Dec 1991 14:07:27 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11953>; Tue, 3 Dec 1991 14:05:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 3 Dec 1991 14:02:42 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11951>; Tue, 3 Dec 1991 14:02:20 PST
Received: from poincare.geom.umn.edu ([128.101.25.31]) by alpha.xerox.com with SMTP id <11754>; Tue, 3 Dec 1991 13:59:08 PST
Received: from euclid.geom.umn.edu by poincare.geom.umn.edu; Tue, 3 Dec 91 15:59:17 CST
Received: by euclid.geom.umn.edu; Tue, 3 Dec 91 15:59:18 CST
X-Ns-Transport-Id: 08002008D0FD00145CD4
Message-Id: <9112032159.AA12652@euclid.geom.umn.edu>
Date: 	Tue, 3 Dec 1991 13:59:18 PST
From: nils@geom.umn.edu
To: MOO-Cows.PARC@xerox.com
Subject: ack.

ack. i mean preposition, not predicate. sorry.



From pavel@parc.xerox.com Fri Dec  6 10:49:31 1991
X-VM-Attributes: [t nil nil nil nil]
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB24115; Fri, 6 Dec 91 10:49:30 PST
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11824>; Fri, 6 Dec 1991 10:48:06 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11787>; Fri, 6 Dec 1991 10:41:22 PST
Received: by lambda.parc.xerox.com id <58371>; Fri, 6 Dec 1991 10:36:42 -0800
X-Ns-Transport-Id: 08002008D0FD00148653
Message-Id: <91Dec6.103642pst.58371@lambda.parc.xerox.com>
Date: 	Fri, 6 Dec 1991 10:36:37 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: New LambdaMOO server released: Version 1.5.9

I have released a new version of the LambdaMOO server, fixing several bugs that
could (and sometimes did) lead to database corruption.  The new code is
available for FTP from the usual place, parcftp.xerox.com, in the file
LambdaMOO-1.5.9.tar.Z.

Here's what ChangeLog.txt has to say about this release:

Version 1.5.9, 6 December 1991
-- Gave different ticks/seconds limits to non-input tasks. They get only 15,000
   ticks and 5 seconds.
-- The task seconds limit is now measured in server CPU seconds (as opposed to
   wall-clock seconds) on systems that can support it.
-- Adding some simple object-hierarchy checking and (in very simple cases)
   repair code to the DB reading process.  If unfixable errors are found, the
   server refuses to run.
-- Fixed minor inconsistency in the log format.
-- Fixed a few minor memory leaks.
-- Fixed a bug whereby the bottom frame of a suspended task that was read from
   the database file could be given the wrong size runtime value stack.
-- Made the DB-reading code a bit pickier about the correctness of its input.
-- Tweaked create() to make it more properly initialize the new object's
   location and contents.
-- Fixed bug in move() that could be tickled if an `accept' verb recycled
   either the movee or the destination.
-- Fixed several bugs in recycle() that could (and did!) corrupt the contents
   hierarchy in the database.  The implementation is now much simpler, too!

Enjoy!

	Pavel/Haakon/Lambda

From pavel@parc.xerox.com Fri Dec  6 16:55:51 1991
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA25384; Fri, 6 Dec 91 16:55:50 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11954>; Fri, 6 Dec 1991 16:54:38 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11855>; Fri, 6 Dec 1991 16:52:38 PST
Received: by lambda.parc.xerox.com id <58371>; Fri, 6 Dec 1991 16:50:12 -0800
X-Ns-Transport-Id: 08002008D0FD00148BE4
Message-Id: <91Dec6.165012pst.58371@lambda.parc.xerox.com>
Date: 	Fri, 6 Dec 1991 16:50:08 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: Finally: New LambdaCore database!

I have finally released a new version of the LambdaCore database.  It is
available for anonymous FTP from host `parcftp.xerox.com', directory `pub/MOO',
file `LambdaCore-6Dec91.db'.

I don't have a list of what all has changed in the core since the last release,
over 3 months ago, but I'm sure there's all sorts of fancy new features and
fixed bugs.

Enjoy!

	Pavel

From mjp@hplb.hpl.hp.com Mon Dec  9 03:30:53 1991
Return-Path: <mjp@hplb.hpl.hp.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA27774; Mon, 9 Dec 91 03:30:52 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11544>; Mon, 9 Dec 1991 03:29:47 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11545>; Mon, 9 Dec 1991 03:26:27 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 9 Dec 1991 03:23:30 -0800
Received: from hplb.hpl.hp.com ([15.255.59.2]) by alpha.xerox.com with SMTP id <11547>; Mon, 9 Dec 1991 03:23:16 PST
Received: from prudence.hpl.hp.com by hplb.hpl.hp.com; Mon, 9 Dec 91 11:14:16 GMT
Received: by prudence.hpl.hp.com with SMTP
	(15.11/15.6+ISC) id AA13824; Mon, 9 Dec 91 11:18:49 gmt
X-Ns-Transport-Id: 08002008D0FD0014998B
Message-Id: <9112091118.AA13824@prudence.hpl.hp.com>
Date: 	Mon, 9 Dec 1991 03:18:48 PST
From: Mike Prudence <mjp@hplb.hpl.hp.com>
To: MOO-cows@parc.xerox.com
Subject: Re: New LambdaCore database!

Hi folks,

Recently Pavel Curtis <pavel@parc.xerox.com> said:

> I have finally released a new version of the LambdaCore database.
> I don't have a list of what has changed in the core since the last release,
> over 3 months ago, but I'm sure there's all sorts of fancy new features and
> fixed bugs.

This may be a question that is totally irrelevant for 99% of the
people who are on this mailing list, but I think it is fairly
important for the few of us who are running LambdaMOO servers of our
own.

        There is no simple path for upgrading our databases to a new
                         LambdaCore version.

To elaborate, the MOO I run was started about 8 months ago, and we
started building on the LambdaCore that was around 8 months ago.
Since then, there have been two or three new LambdaCore snapshots
released, and each time I have been faced with a problem:  do I try
and incorporate the new features from the new snapshot, or do I ignore
the advances made, and stay with the database we've got.

The first option involves a LOT of work.  I tried it for a few core
classes a few months ago, and it can result in a terrible mess.  For
example, I tried to update our $string_utils class to the latest and
greatest.  Pure folly, as this breaks virtually every core verb we had
in our database.  Plus, I ended up having to copy over the generic
database class for the player database, and this mucked up other
things and ......

You get the idea.

I guess my questions are numbered two:

	(1) Has anyone found a simple, foolproof method for updating
an exisiting database to a new lambdacore version ?

 	(2) If not, Pavel - is there any chance that some sort of
upgrade support can be provided by you ?  (eg, perhaps a program to
merge two databases, or a better encapsulation of the core so that a
new one can just be slotted in ?)

I'm prepared to live with the code that *we* have written being a little
cranky with a new core in place - that is really our problem.
However, it would be nice to just be able to slot in the hard work
that the folks at LambdaMOO put into their core database. 

After all, isn't that a lot of the reason for releasing these
snapshots ??

Comments, ideas, code (!)  ???

Cheers,

Mike

mjp@hplb.hpl.hp.com   "Human beings were invented by water to carry it uphill."

From pavel@parc.xerox.com Mon Dec  9 09:59:41 1991
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA28300; Mon, 9 Dec 91 09:59:40 PST
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11590>; Mon, 9 Dec 1991 09:58:14 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11575>; Mon, 9 Dec 1991 09:53:29 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 9 Dec 1991 09:49:10 -0800
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11587>; Mon, 9 Dec 1991 09:48:32 PST
Received: by lambda.parc.xerox.com id <58372>; Mon, 9 Dec 1991 09:48:24 -0800
X-Ns-Transport-Id: 08002008D0FD00149CEC
In-Reply-To: <9112091118.AA13824@prudence.hpl.hp.com>
Message-Id: <91Dec9.094824pst.58372@lambda.parc.xerox.com>
Date: 	Mon, 9 Dec 1991 09:48:20 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-cows@parc.xerox.com
Subject: Re: New LambdaCore database!

Mike Prudence writes:
>  	(2) If not, Pavel - is there any chance that some sort of
> upgrade support can be provided by you ?  (eg, perhaps a program to
> merge two databases, or a better encapsulation of the core so that a
> new one can just be slotted in ?)

This is obviously an important problem, one among many.

I have, on occasion, given some thought to the design of a tool for merging a
new core database into some other DB.  There are a lot of tricky issues,
though, concerned with properly matching up objects that have different numbers
in the two DBs but are really `the same' and with knowing which changes are
good/bad to impose on the existing DB.  Of course, the easiest way around this
problem is to put a human in the loop.  I may, at some point, write such a
tool, but it's unlikely to be very soon.  I'm only one person and I already
have a lot of stuff on my queue.

> After all, isn't that a lot of the reason for releasing these snapshots ??

Not really, especially because of the upgrade problem.  Really, I release new
snapshots so that any new MOOs starting up can take advantage of the most
recent stuff at LambdaMOO.

	Pavel

From yduj@lucid.com Mon Dec  9 15:08:55 1991
Return-Path: <yduj@lucid.com>
Received: from alpha.Xerox.COM by palain.PARC (4.1/SMI-4.1)
	id AB29336; Mon, 9 Dec 91 15:08:54 PST
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11661>; Mon, 9 Dec 1991 15:06:27 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11640>; Mon, 9 Dec 1991 15:03:31 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 9 Dec 1991 14:59:29 -0800
Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <11653>; Mon, 9 Dec 1991 14:58:42 PST
Received: from boston-harbor (boston-harbor.lucid.com) by heavens-gate.lucid.com id AA27670g; Mon, 9 Dec 91 14:56:20 PST
Received: by boston-harbor id AA21087g; Mon, 9 Dec 91 17:58:56 EST
X-Ns-Transport-Id: 08002008D0FD0014A2BF
In-Reply-To: "Mike Prudence's message of Mon, 9 Dec 1991 03:18:48 PST <9112091118.AA13824@prudence.hpl.hp.com>"
Message-Id: <9112092258.AA21087@boston-harbor>
Date: 	Mon, 9 Dec 1991 14:58:56 PST
From: Judy Anderson <yduj@lucid.com>
To: mjp@hplb.hpl.hp.com
Cc: MOO-cows@parc.xerox.com
Subject: New LambdaCore database!

I can imagine writing a program which would run on LambdaMOO, go
through the core, and emit for each object a selection of commands to
update that object.  Indeed there are a couple such programs already
which produce download scripts; I'm suggesting a much fancier one.

One thing that could be done is to write a verb that accepted a string
such as "list_utils" and info about parent, check if there was a core
object called that already, if there wasn't, to create the #0.(prop),
and create the object.  Then, use a fancier version of @verb which
dwim'd about whether you wanted @verb to make a new verb or @args to
change the arguments.  (I believe it is the case that there are no
core objects which have two verbs with the same name but different
arguments, something that could break such dwim.)  You'd have to
download these first to the target MOO.  There are probably a lot of
pitfalls in this, like you'd want to know what verbs and properties
had been deleted from a core object, which could only be done on the
target moo, and you'd have to be careful about which core verbs you
used in the download script in case they changed out from under you in
the midst of the update...  But I don't *think* there's anything
preventing this from being written in moo-code (except that you'd have
>>Output Flushed<< a bazillion times and downloading the resulting
script would get an error and generally it would be a pain).

Note this message does not constitute a promise to write this utility :-)

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

From dxb105@phyvs1.anu.edu.au Mon Dec  9 16:14:50 1991
Return-Path: <dxb105@phyvs1.anu.edu.au>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA29516; Mon, 9 Dec 91 16:14:49 PST
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11687>; Mon, 9 Dec 1991 16:11:04 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11658>; Mon, 9 Dec 1991 15:49:39 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Mon, 9 Dec 1991 15:45:27 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11730>; Mon, 9 Dec 1991 15:33:43 PST
Received: from phyvs1.anu.edu.au ([150.203.15.75]) by alpha.xerox.com with SMTP id <11747>; Mon, 9 Dec 1991 15:21:22 PST
Received: by phys.anu.edu.au (MX V2.3) id 20774; Tue, 10 Dec 1991 10:19:58 EST
X-Ns-Transport-Id: 08002008D0FD0014A31E
Message-Id: <00952E62.78B22020.20774@phys.anu.edu.au>
Date: 	Tue, 10 Dec 1991 07:19:58 PST
From: David Bofinger <dxb105@phyvs1.anu.edu.au>
To: MOO-Cows.PARC@xerox.com
Cc: dxb105@phyvs1.anu.edu.au
Subject: Updating Gadgets

As I see it, you need a program that contains three databases:

	* The !Lambda database
	* The new LambdaCore
	* The LambdaCore that the !Lambda DB was
		- made from
		- last updated from

Then the program uses the $foobar abbreviations to work out which verbs are
supposed to be doing the same job, and replaces every verb that has changed
between LambdaCores but hasn't been changed in the new DB.

We'd still need a hominid in the loop, but I think this would mostly do the
right thing. Mostly.

------------------------------------------------------------------------------
David Bofinger	AARNet:	dxb105@phys.anu.edu.au
                Snail:	Dept. of Theoretical Physics, RSPhysSE, ANU, ACT, 2601
		MOO:	US, Japan, Germany, France, Italy, UK, Canada(?)
------------------------------------------------------------------------------
"Out of the cradle, endlessly looping"

From pavel@parc.xerox.com Fri Dec 13 12:06:01 1991
Return-Path: <pavel@parc.xerox.com>
Received: from alpha.xerox.com by palain.PARC (4.1/SMI-4.1)
	id AA09165; Fri, 13 Dec 91 12:06:00 PST
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11873>; Fri, 13 Dec 1991 12:03:57 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11868>; Fri, 13 Dec 1991 11:58:12 PST
Received: by lambda.parc.xerox.com id <58371>; Fri, 13 Dec 1991 11:55:51 -0800
X-Ns-Transport-Id: 08002008D0FD0014DD56
Message-Id: <91Dec13.115551pst.58371@lambda.parc.xerox.com>
Date: 	Fri, 13 Dec 1991 11:55:36 PST
From: Pavel Curtis <pavel@parc.xerox.com>
To: MOO-Cows@parc.xerox.com
Subject: New LambdaCore database

I've just released a new version of the LambdaCore database, fixing some
problems with the logs maintained by the wizard commands @programmer and
@quota.  As usual, it is available for anonymous FTP from host
`parcftp.xerox.com', file `pub/MOO/LambdaCore-13Dec91.db'.

	Pavel

