# Production release 1.8.0 of the LambdaMOO server

Pavel Curtis (pavel@parc.xerox.com)
Sat, 9 Mar 1996 17:42:04 PST

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

    I have, at long last, made the final, production release of version 1.8.0 of
    the LambdaMOO server, in the usual place:

    	ftp://ftp.parc.xerox.com/pub/MOO/LambdaMOO-1.8.0.tar.Z

    This release contains a *very* large number of changes from the last production
    release, 1.7.9p2; you are *strongly* advised to read through the ChangeLog.txt
    file before upgrading.  Remember to look for any entries marked `NOTE' before
    upgrading; these include changes you should make to your database *before*
    switching over to the new release.

    This marks the last non-patch release of LambdaMOO that I, personally, will be
    making.  I hope soon to announce who will be taking over the server-code
    maintenance job from me in the future.  It has been an incredible 5-1/2 years
    writing code for and learning from the MOO community and I wouldn't trade that
    experience for anything.  Thank you all very much; you've been supportive and
    full of energy and ideas for that whole time.  I know I'll miss this as I move
    on to my new directions.

    	Pavel

    Here's the ChangeLog.txt entry for just the changes since 1.8.0beta3:
    -------------------------------------------------------------------------------
    Version 1.8.0, 9 March 1996
    -- Verbs defined on #0 are no longer subject to the wiz-only permissions check
       on built-in functions generated by defining $server_options.protect_FOO with
       a true value.  Thus, you can now write a `wrapper' for a built-in function
       without having to re-implement all of the server's built-in permissions
       checks for that function.  (Thanks to ThwartedEfforts for bringing this idea
       back to my attention.)
    -- If a built-in function FOO has been made wiz-only (by defining
       $server_options.protect_FOO with a true value) and a call is made to that
       function from a non-wiz verb not defined on #0 (that is, if the server is
       about to raise E_PERM), the server first checks to see if the verb #0:bf_FOO
       exists.  If so, it calls it instead of raising E_PERM and returns or raises
       whatever it returns or raises.  (Thanks to yduJ and ThwartedEfforts for
       putting this idea together.)
    -- Added the source code for `pgperf' to a subdirectory of the release `tar'
       file.  You need `pgperf' in order to recreate the keyword-lookup table used
       in the MOO-code parser should you ever change the set of keywords accepted
       by the parser.  Check out the `pgperf/README' file for (slightly) more
       information.
    -- Backed out the change in 1.8.0beta3 where the parser was replacing calls of
       the form `call_function("foo", ...)'  with simply `foo(...)' if `foo' was a
       known function.  While this change made sense for porting whole databases
       between server versions, it made it harder to port single verbs or objects
       from place to place.  (Thanks to Richard Connamacher for being persistent
       enough to finally make me see this point.)
    -- Added new built-in function `connection_option(CONN, OPTION)', which returns
       the current setting of the option OPTION on the connection CONN.  It raises
       E_INVARG if OPTION is not a valid option for that connection.  (Thanks to
       Don Schwarz for pointing out how inconvenient it could be to have to use
       `connection_options(CONN)' for this.)
    -- Changed the format of binary strings to have non-printing characters
       represented in hexadecimal instead of octal, for improved concision and
       consistency with the output of the `*_hash()' functions.  (Thanks to
       ThwartedEfforts for suggesting this.)
    -- Made optional the argument to `shutdown()'.  (Thanks to Richard Godard for
       suggesting this.)
    -- Moved the DEFAULT_PORT and DEFAULT_CONNECT_FILE options into `options.h'.
       (Thanks to Richard Godard for suggesting this, too.)
    -- Fixed line numbers reported in load-time warnings about renaming old uses of
       new keywords.  (Thanks to Ron Stanions and others for noticing this bug.)
    -------------------------------------------------------------------------------