# MOO-Cows Digest V1 #323

MOO-Cows-Errors@parc.xerox.com (MOO-Cows-Errors@parc.xerox.com)
Wed, 31 Jan 1996 10:34:51 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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-*