MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
MOO-Cows Digest V1 #323
MOO-Cows Digest Wednesday, 31 January 1996 Volume 01 : Number 323
In this issue:
Re: MOO-Cows Mailing list changes
Re: MOO-Cows Mailing list changes
Re: MOO-Cows Mailing list changes
E_NACC
Re: E_NACC
RE: Logging and Security Hole.
[SERVER] wishlist (was: logging)
Re: [SERVER] wishlist (was: logging)
Wishlist: verbs that return control to the system...
Re: Wishlist: verbs that return control to the system...
Re: [SERVER] wishlist (was: logging)
See the end of the digest for information on subscribing to the MOO-Cows
or MOO-Cows-Digest mailing lists and on how to retrieve the list archives.
----------------------------------------------------------------------
From: kbobrow@parc.xerox.com (Kimberly Bobrow)
Date: Tue, 30 Jan 1996 12:27:57 -0800
Subject: Re: MOO-Cows Mailing list changes
>I want to take this opportunity to publicly thank Kim for taking on this job
>(and taking it off *my* shoulders). She's a real trooper! I'd also like to
>thank the several other people who volunteered to take over the mailing list;
>in the end, I decided to take the offer nearest at hand, in order to minimize
>the disruption to the list itself.
:figures she probably ought to step out of the shadows and say hi, so, um, HI!
- --Kimberly
// Kimberly Bobrow
// kbobrow@parc.xerox.com She's e-mailing, she must be
// kimberly@soho.ios.com having an out-of-moo experience!
------------------------------
From: Richard Connamacher <phantom@baymoo.sfsu.edu>
Date: Tue, 30 Jan 1996 11:05:03 -0800
Subject: Re: MOO-Cows Mailing list changes
Kimberly Bobrow wrote:
> :figures she probably ought to step out of the shadows and say hi, so, um, HI!
Hi right back! Thanks for taking on moo-cows! We all love you! :-)
Phantom
------------------------------
From: kbobrow@parc.xerox.com (Kimberly Bobrow)
Date: Tue, 30 Jan 1996 14:04:03 -0800
Subject: Re: MOO-Cows Mailing list changes
On Tue, 30 Jan 1996 11:05:03 -0800 you wrote:
>Kimberly Bobrow wrote:
>
>> :figures she probably ought to step out of the shadows and say hi, so, um, HI!
>
>Hi right back! Thanks for taking on moo-cows! We all love you! :-)
>
>Phantom
Oh no no no no no.. *I* love all of *you*!!! <lol> Thanks for the warm welcome!
- --Hobbes
whoops - Kimberly ;>
// Kimberly Bobrow
// kbobrow@parc.xerox.com She's e-mailing, she must be
// kimberly@soho.ios.com having an out-of-moo experience!
------------------------------
From: Rich Connamacher <phantom@baymoo.sfsu.edu>
Date: Tue, 30 Jan 1996 23:03:34 -0800
Subject: E_NACC
I'm just curious..
What does NACC actually stand for? Was it an obsolete error code that
was renamed, like E_QUOTA was in 1.8.0?
Thanks
Phantom
------------------------------
From: Andrew Wendt <powerpig@m-net.arbornet.org>
Date: Wed, 31 Jan 1996 01:14:53 -0800
Subject: Re: E_NACC
> What does NACC actually stand for? Was it an obsolete error code that
> was renamed, like E_QUOTA was in 1.8.0?
I always thought it was Not ACCepted, because it is raised by move() if
:accept() on the destination object returns false.
TTFN
Andy
------------------------------
From: Andrew Wendt <powerpig@m-net.arbornet.org>
Date: Wed, 31 Jan 1996 02:12:46 -0800
Subject: RE: Logging and Security Hole.
On Tue, 30 Jan 1996, C. Regis Wilson wrote:
> >Secondly, I'd like a way to log all commands that a grey listed site
> >issues into the server log.. I think all I have to do is modify the
> >$command_utils:do_huh, but I think that this would be a nice addition to
> >the next LambdaCore. Since Greylisting is suppose to be a warning of
> >problems, have it log all commands from those sites.. Comments Welcome.
>
> I don't think you can do this without in-db parsing. But,
> if it's in-db, it can be loop-holed or hacked. You'd have
> to have the server log the commands in some way, but then
> (in my opinion) you violate the theory of "division of
> server and db".
I don't think $command_utils:do_huh is a good choice for this. This would
probably work fine if you put it in #0:do_command:
su=$string_utils;
if ($login:graylisted(su:connection_hostname(connection_name(player))))
server_log(tostr(su:nn(player),": ",argstr));
endif
Since :do_command returns false the server continues with the command
anyway. It has to call $login and $string_utils before every single
command though, even if you're not being logged.
I don't think logging commands is a very nice thing to do in the first
place anyway, and users should be notified at login if there is the
possibility of it. Perhaps only log commands that match a certain pattern
(all those starting with `@'?) would be nicer.
Something totally unrelated in case I'm wrong about how to log people, so
this message might still be worth something, here is something I've
wanted:
with ($string_utils)
x=:explode(argstr);
y=.alphabet;
endwith
You get the idea. You don't have to specify $string_utils over and over
if you use it a lot.
> >In Him, for Him
> >
> Is this one of those Christian subliminal messages?
TTFN
Andy
- --
Which word doesn't belong: Andrew Wendt
Christianity, Hypocrisy, Lies, Trickery, Sheep powerpig@arbornet.org
"andy is the prince of darkness" -- draco powerpig@mcmuse.mc.maricopa.edu
------------------------------
From: bmgustav@bioinformatics.weizmann.ac.il (Gustavo Glusman)
Date: Wed, 31 Jan 1996 03:33:54 -0800
Subject: [SERVER] wishlist (was: logging)
Andrew>
>with ($string_utils)
> x=:explode(argstr);
> y=.alphabet;
>endwith
>
>You get the idea. You don't have to specify $string_utils over and over
>if you use it a lot.
I don't really see how this is better than:
su = $string_utils;
x = su:explode(argstr);
y = su.alphabet;
...which is the common practice.
Implementing the 'with/endwith' structure wouldn't really add any
functionality, would probably add lots of parsing intricacies and reduce
readability.
Probably people would then complain about being restricted to 'just one
default value', which has to be of 'just one data type'. Using local vars
solves all this.
What I think would be handy (and has been suggested already) is a way to
undeclare vars, e.g. 'release(foo);'. OTOH, as was pointed out, doing 'foo
= E_VARNF;' is almost as good. :)
:goes to get some coffee, and to try to think why he wrote 'almost'.
- -------------------------------------------------------------
Gustavo Glusman Founder/administrator of BioMOO
- -- Gustavo@bioinformatics.weizmann.ac.il
- -- http://bioinformatics.weizmann.ac.il/Gustavo
- -- BioMOO: telnet bioinformatics.weizmann.ac.il 8888
WWW: http://bioinfo.weizmann.ac.il:8888
------------------------------
From: mcmudge@mailbox.syr.edu (Kipp the Kidd)
Date: Wed, 31 Jan 1996 05:50:19 -0800
Subject: Re: [SERVER] wishlist (was: logging)
>What I think would be handy (and has been suggested already) is a way to
>undeclare vars, e.g. 'release(foo);'. OTOH, as was pointed out, doing 'foo
>= E_VARNF;' is almost as good. :)
I agree. I too often write programs where I include way too many variables
and wish to free up a few, especially in really big tasks like a
path-to-room search...
I'm still trying to figure out if this would be good or not:
What if the variable 's' wasn't defined, and the parser was given this:
s=s+" ";
How hard would it be to make 's' default to "" (or 0 or {} or 0.0)? It
might speed up performance (a little)...
- - Kipp
`-!@#$%^&*()_+|\=-~`-!@#$%^&*()_+|\=-~`-!@#$%^&*()_+|\=-~`-!@#$%^&*()_+|\=-~`-!
` Kipp - Michael Mudge # I like to live close to home # Syracuse !
` Owner of MOO2000 # moo.microwave.com 2000 # New York !
`-!@#$%^&*()_+|\=-~`-!@#$%^&*()_+|\=-~`-!@#$%^&*()_+|\=-~`-!@#$%^&*()_+|\=-~`-!
------------------------------
From: Ron Stanions <chaeon@roc.clawpaw.com>
Date: Wed, 31 Jan 1996 06:55:36 -0800
Subject: Wishlist: verbs that return control to the system...
Yeah I know it's probably too late in the game but I keep thinking about =
something that I'd like whenever I'm not near my keyboard to talk about =
it... This time I got lucky.
What I'd like to see is some way for verbs to return or maybe raise a =
condition which would cause the command parser to continue normal =
processing as if it had never attempted to use this verb.
For example:due to the order of processing if I put a 'L*ook any any =
any' on myself it's going to override all other occurances of look. My =
version of look only handles look, look object, and look at object. =
Problem is, if I make a dresser and want to be able to 'look on dresser' =
or 'look in dresser' I need to put those variations of the look command =
on the dresser. However, since my look got first dibs it was given the =
task of processing it. it would be really nifty if I could have =
somewhere in my code where if (nothingdone) raise E_DISCARD or =
something which causes the server to resume looking for a 'look' on =
other objects.
This could be useful for many other reasons. I could put a 'get' on the =
room that modifies the way get works, (changes dobj and iobj) then =
tosses control back to the main handlers with these new variables in =
place. It opens up some interesting possibilities.
- --
chaeon@roc.clawpaw.com -- Site admin for clawpaw.com =
http://www.clawpaw.com
Chaeon - Site Wiz or K'ryn - Bronze rider, VirtuaPern Moo =
http://www.clawpaw.com/VirtuaPern
VirtuaPern MOO - telnet dragon.clawpaw.com port 9999
------------------------------
From: ThwartedEfforts <abakun@scinc.com>
Date: Wed, 31 Jan 1996 07:25:43 -0800
Subject: Re: Wishlist: verbs that return control to the system...
At 06:55 AM 1/31/96 PST, Ron Stanions wrote:
>What I'd like to see is some way for verbs to return or maybe raise a
> condition which would cause the command parser to continue normal
> processing as if it had never attempted to use this verb.
While an error code to this effect (I just use E_NACC) might be handy, I
throught we were trying to (hopefully) steer away from server parsing.
(advertisement: http://tecfa.unige.ch:4243/project_docs/in-db-parsing -- to
be released soon)
>For example:due to the order of processing if I put a 'L*ook any any any'
> on myself it's going to override all other occurances of look. My version
> of look only handles look, look object, and look at object. Problem is, if
> I make a dresser and want to be able to 'look on dresser' or 'look in
> dresser' I need to put those variations of the look command on the dresser.
> However, since my
First off, you should be using :look_self. Second off, all that needs to be
done is to make $room:look smarter so it will work without 'any any any',
then define ':look on this none none' on the dresser. In fact, the code in
:look_self could even examine the prepstr variable to see if it was being
examined 'on' or 'in' or 'at'.
>look got first dibs it was given the task of processing it. it would be
> really nifty if I could have somewhere in my code where if (nothingdone)
> raise E_DISCARD or something which causes the server to resume looking for
> a 'look' on other objects.
Server parsing is relatively simple, find the prep and objects in the
string, search for verbs that match those, then call the verb.
>This could be useful for many other reasons. I could put a 'get' on the
room that modifies the way get works, (changes dobj and iobj) then tosses
control back to the main handlers with these new variables in place. It
opens up some interesting possibilities.
Wouldn't this require a change to the scoping rules for builtin variables,
since they would then be propagated back through verb calls?
Something else to consider, what happens if the first call suspends(), but
then raises E_DISCARD? yuck.
More discussion on this topic can be found at
http://shrike.depaul.edu/~abakun/moomail/
I know this has been talked about before.
------------------------------
From: "Robert J. Brown" <rj@eli.wariat.org>
Date: Wed, 31 Jan 1996 10:32:56 -0800
Subject: Re: [SERVER] wishlist (was: logging)
>>>>> "Kipp" == Kipp the Kidd <mcmudge@mailbox.syr.edu> writes:
>> What I think would be handy (and has been suggested already) is
>> a way to undeclare vars, e.g. 'release(foo);'. OTOH, as was
>> pointed out, doing 'foo = E_VARNF;' is almost as good. :)
Kipp> I agree. I too often write programs where I include way too
Kipp> many variables and wish to free up a few, especially in
Kipp> really big tasks like a path-to-room search...
Kipp> I'm still trying to figure out if this would be good or not:
Kipp> What if the variable 's' wasn't defined, and the parser was
Kipp> given this:
Kipp> s=s+" ";
Kipp> How hard would it be to make 's' default to "" (or 0 or {}
Kipp> or 0.0)? It might speed up performance (a little)...
Some Lisp systems permit you to undefine a variable *ONLY* if there
are no other references to it. The way this works is the variable is
tagged as permitting undefinition when you say (UNDEFINE <var>), but
it still hangs around until the next garbage collection. If the
garbage collection only finds the variable is on the OBLIST, but with
no other references, then it is removed from the OBLIST and freed up.
- --
- ----------- "... And the men went up and viewed Ai." [Jos 7:2] -----------
Robert Jay Brown III rj@eli.wariat.org http://eli.wariat.org 1 708 705-0370
Elijah Laboratories Inc; 759 Independence Drive; Suite 5; Palatine IL 60074
- ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------
------------------------------
End of MOO-Cows Digest V1 #323
******************************
To subscribe to MOO-Cows-Digest, send the command:
subscribe MOO-Cows-Digest
in the body of a message to "MOO-Cows-Request@PARC.Xerox.Com". If you
want to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-moo-cows":
subscribe MOO-Cows-Digest local-moo-cows@your.domain.net
A non-digest (message-by-message) version of this list is also available; to
subscribe to that instead, replace all instances of "MOO-Cows-Digest" in the
commands above with simply "MOO-Cows".
The archives of the MOO-Cows mailing list is available from the files
ftp://ftp.parc.xerox.com/pub/MOO/mail/MOO-Cows-*
Home |
Subject Index |
Thread Index