# BETA-TEST release of LambdaMOO version 1.8.0beta1

Pavel Curtis (pavel@parc.xerox.com)
Wed, 7 Feb 1996 23:42:44 PST

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

    I have made the first of probably several *beta-test* releases of version 1.8.0
    of the LambdaMOO server in the usual place:

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

    This is now a BETA TEST release of the server.  That means that no more major
    feature additions will be made before the production release.  It also means
    that we are entering the home stretch of the testing process.  I would
    appreciate it if every current MOO server site would consider fetching a copy
    of this release and trying it out on a copy of your production database.  The
    more adventurous of you might even consider trying a single-day full production
    test using this release.  If you do this, though, PLEASE SAVE A COPY OF YOUR
    OLD DATABASE; you will almost certainly want to roll back to the old server
    release and the old database after the one-day test.  This implies that, if you
    do this, you should warn your users that their DB changes on that day will not
    be saved.  IT IS NOT POSSIBLE to use a DB file written by 1.8.0beta1 and use it
    with *any* earlier release; it's a one-way street.

    Other than the temporary testing suggestion given above, please be aware that
    there are almost certainly some more server-crashing, database-losing bugs
    remaining, so please DO NOT USE THIS RELEASE IN A PRODUCTION SETTING!

    Please continue to send your bug reports to the main MOO-Cows mailing list.  As
    before, critical bug fixes will either be posted to MOO-Cows-Announce or else
    released in later beta releases.

    Thanks in advance for your help in testing out this release!

    	Pavel

    Here's the ChangeLog.txt entry for this release:
    -------------------------------------------------------------------------------
    Version 1.8.0beta1, 7 February 1996
    -- Fixed bug where scattering assignment was not checking for the right-hand
       side value being a list, and a severe bug where errors in a scattering
       assignment in a !d verb caused the interpreter to execute many of the
       operands of the EOP_SCATTER instruction as if they were opcodes.  (Thanks to
       Kipp the Kid for finding this problem.)
    -- Changed several routines to panic the server instead of simply logging an
       error message; these were places where such an error indicated a memory
       smash or some other very serious error had occurred; it made no sense to try
       to press on with normal operations.  This eliminates the "Impossible var
       type" log messages sometimes seen from FREE_VAR, VAR_REF, and VAR_DUP.
    -- Added support for in-DB handling of all tracebacks, of which there are two
       kinds: unhandled errors and tasks that have timed out.
          If an error is raised and not caught, then the verb-call
              #0:handle_uncaught_error(CODE, MSG, VALUE, TRACEBACK, FORMATTED)
       is made, where CODE, MSG, VALUE, and TRACEBACK are the values that would
       have been passed to a `try-except-endtry' handler for the error and
       FORMATTED is a list of strings being the lines of traceback output that
       will be printed to the player.
          If a task runs out of ticks or seconds, then the verb-call
              #0:handle_task_timeout(RESOURCE, TRACEBACK, FORMATTED)
       is made, where RESOURCE is the appropriate one of the strings "ticks" or
       "seconds", and TRACEBACK and FORMATTED are as above.
          In both situations, the indicated verb call is made with the same
       task_id() as the task that caused the traceback.  If the handler verb call
       either suspends or returns a true value, then that code is considered to
       have handled the traceback and no further processing will be done by the
       server.  On the other hand, if the appropriate handler verb does not exist,
       or returns a false value without suspending, or itself causes a traceback,
       the original traceback (i.e., FORMATTED) will be printed to the player as in
       earlier versions of the server.
          Note that, if the handler verb-call itself causes a traceback, no
       `nested' handler call is made; its traceback is simply printed to the player
       without further processing.  This prevents what might otherwise be quite a
       nasty vicious cycle.
          (Thanks to ThwartedEfforts for suggesting such a feature.)
    -- Added a way to flush all pending input on a given connection, mostly for use
       by users who change their minds about having typed something and can react
       before the server has processed it.  Each connection may have a defined
       `flush command'; if a raw line of input is equal to that connection's flush
       command, then all pending input on the connection is flushed and a message
       is printed back to the connection describing what happened.  By default,
       each connection's flush command is `.flush'; you can change this default by
       setting $server_options.default_flush_command either to a non-empty string
       (the new default) or something else (a default of `no defined flush
       command').  On any given connection, you can redefine the flush command with
    	set_connection_option(CONN, "flush-command", VALUE)
       Again, if VALUE is a non-empty string, it becomes the new flush command for
       CONN; otherwise, CONN is set to have no defined flush command.
       ********** This could confuse things for certain kinds of unusual server
       ** NOTE ** connections, such as outbound ones or ones to non-MOO servers
       ********** running in the database (e.g., HTTP servers).  You may want to
       set $server_options.default_flush_command to the empty string (to disable
       flush commands by default) and use set_connection_option() to change this
       just for appropriate connections (e.g., in #0:do_login_command).
          (Thanks to Kent Pitman and others for help in designing this feature.)
    -- Added the `connection_options(CONN)' built-in function, which returns a list
       of {NAME, VALUE} pairs describing the current settings of all of the allowed
       options for the connection CONN.  (Thanks to Brian Buchanan for suggesting
       this.)
    -- Added `list' and `disassemble' commands to emergency wizard mode.  (Thanks
       to H. Peter Anvin for writing the first versions of these.)
    -- Added a new `named' form of the `while' loop:
    		WHILE id (expression)
    		  statements
    		ENDWHILE
       This behaves exactly like the statement
    		WHILE (id = (expression))
    		  statements
    		ENDWHILE
       This was added solely to provide a way to give a name to a `while' loop, for
       use in the new `break' and `continue' statements, described below.
    -- Added new MOO statements `break' and `continue', similar to the ones in C or
       Java.  The syntax is
    		BREAK [id];
    		CONTINUE [id];
       A `break' statement causes your program to exit an enclosing `for' or
       `while' loop; a `continue' statement causes your program to skip ahead to
       the begining of the next iteration of an enclosing loop.  If provided, the
       ID in the `break' or `continue' statement specifies which enclosing loop is
       meant; ID should be the variable name appearing directly after the `for' or
       `while' keyword in the desired loop.  If no ID is provided, the innermost
       enclosing loop is indicated.  If a `break' or `continue' statement causes
       control to leave the main body of a `try - finally - entry' statement, the
       `finally' part will be executed first, just as with a `return' statement.
          Here's an example:
    		x = 0;
    		for i in [1..5]
    		  notify(player, "top");
    		  try
    		    if (!x)
    		      x = 1;
    		      notify(player, "continuing");
    		      continue;
    		    endif
    		    x = x + 1;
    		  finally
    		    notify(player, "finally");
    		  endtry
    		  notify(player, "after");
    		  if (x > 1)
    		    break;
    		  endif
    		endfor
    		notify(player, "done");
       This verb produces the following output:
    		top
    		continuing
    		finally
    		top
    		finally
    		after
    		done
       I don't claim that this is a useful verb, mind you, but it does illustrate
       all of the possible interactions.
    -- By popular demand, I added the new built-in function
    	force_input(CONN, LINE [, AT_FRONT])
       which inserts the string LINE as an input task in the queue for the
       connection CONN, just as if it had arrived as input over the network.  If
       AT_FRONT is provided and true, then the new line of input is put at the
       front of CONN's queue, so that it will be the very next line of input
       processed even if there is already some other input in that queue.
    -- Fixed a bug whereby the very most common case of resuming a suspended task
       with a new value failed to work.  (Thanks to Brian Buchanan for reporting
       this.)
    -- Changed the server to make a log entry whenever the value of a wizard bit
       changes (as opposed to just when it goes from false to true).  (Thanks to
       Marc <marc@got.net> for this very sensible suggestion.)
    -- Fixed a bug where the server thought it sometimes advisable to parenthesize
       the single-character `$' expression...
    -- Fixed stack-overflow memory-smash bug that could occur if, in a !d verb, the
       `$' expression got a type error.  (Thanks to Kipp the Kid for reporting
       this.)
    -- Fixed a typo in the registration of the functions decode_binary() and
       encode_binary().  (Thanks to Richard Connamacher and H. Peter Anvin for
       finding this.)
    -- Added floating-point numbers as a new MOO value type; this involves a number
       of changes to the behavior of existing MOO primitives, described in the
       following several items.  The representation of these values is in the local
       C compiler's type `double', which is IEEE double precision on almost all
       modern systems.  IEEE infinite and NaN values are not allowed in MOO; the
       new error code E_FLOAT is raised whenever one of these values would
       otherwise be computed.
           (Enormous thanks go to H. Peter Anvin, without whose great
           efforts, understanding, and persistence these floating-point
           facilities would not have made it into any release of the
           server on my watch.  I have not taken his patches without
           modification, but nearly every change I made in adding these
           features was patterned closely on what he had done.  Of course,
           any bugs that still remain in the server are solely my
           responsibility and should not be taken to reflect badly on HPA
           in any way.)
    -- MOO numeric literals now have the following syntax:
    	digit+ [. digit+] [{e | E} [+ | -] digit+]
       The number is represented in floating-point if and only if either a decimal
       point or a scientific-notation marker (`e' or `E') appears in the
       literal.
    -- Added new built-in variables `INT' (with the same meaning as the old `NUM'
       variable) and `FLOAT' (the result of typeof() applied to a floating-point
       number).
    -- Floating-point numbers not equal to 0.0 are treated as `true' in MOO
       conditionals.
    -- Both tostr() and toliteral() display floating-point numbers in the fullest
       available precision, with 15 decimal digits on most machines.
    -- The new built-in function `floatstr(FLOAT, PRECISION [, USE_SCI_NOTATION])'
       can be used to get more control over the conversion of floating-point
       numbers to strings.  In this function, FLOAT is a floating-point number and
       PRECISION is the number of digits to appear to the right of the decimal
       point (at most the maximum available precision, 15 digits on most machines).
       If USE_SCI_NOTATION is false or not provided, the result is a string in the
       form "MMMMMMM.DDDDDD", preceded by a minus sign if FLOAT is negative.  If
       USE_SCI_NOTATION is provided and true, the result is a string in the form
       "M.DDDDDDe+EEE", again preceded by a minus sign if FLOAT is negative.
    -- The following operators now work in the obvious way (analogously to the
       integer case) if X and Y are both floating-point numbers:
    	-X
    	X + Y		X - Y		X * Y		X / Y		X % Y
    	X == Y		X != Y
    	X < Y		X <= Y		X > Y		X >= Y
       If one of X or Y is an integer and the other is a floating-point number,
       then most of these operators raise E_TYPE; there are no automatic coercions
       of integers to floating-point numbers.  The expression (X == Y) is always
       false and (X != Y) always true if X and Y do not have the same type.
           (This is the most major place where I decided to depart from
           HPA's patches; I was persuaded by the discussion on the
           MOO-Cows list that the potential dangers posed by automatic
           coercions in MOO's ubiquitously persistent world outweighed
           their added convenience in some kinds of programs.  It's my
           guess that this decision will generate more dialog on the list,
           and I welcome the input; it's always possible to extend the
           server upward-compatibly later to allow such coercions.)
    -- The following operations all raise E_TYPE if either X or Y is a
       floating-point number:
    	Z[X]		Z[X] = E	Z[X..Y]		Z[X..Y] = E
       List and string indices must be integers.
    -- Added built-in functions `toint()' (a synonym for `tonum()') and
       `tofloat()'.  The former can be used to convert a floating-point number to
       an integer by truncation toward zero.  The latter can be used to convert an
       integer, a floating-point number, an object number, a string containing a
       floating-point literal, or an error value into a floating-point number.
    -- The functions `min()', `max()', and `abs()' now work analogously on
       floating-point numbers.  If `min()' or `max()' are passed some integers and
       some floating-point numbers in the same call, they raise E_TYPE.
    -- ************ The function `sqrt()' no longer accepts integer arguments; its
       *** NOTE *** argument must now be a floating-point number and its result
       ************ will always be such a number.  The old and nearly useless
       behavior of a call to `sqrt(X)' can be simulated with the new expression
       `toint(sqrt(tofloat(x)))'.  (I did this because it made no sense for the
       various new math functions, like `sin()' and `exp()', to map integer
       arguments to integer results and it seemed important to keep all of the math
       functions consistent.  It's my guess that there's very little existing code
       that uses the old `sqrt()' function, so that this will not represent much of
       an upgrading burden; I'm sure you'll let me know if I'm wrong...)
    -- Added a new expression type `X ^ Y', which returns X raised to the power of
       Y.  If X is an integer, then Y must be an integer as well.  If X is a
       floating-point number, then Y may be either integer or floating-point.
           (Yes, maybe this is inconsistent with the complete lack of
           coercions described above; feel free to try to argue me around
           to a position you think is better.)
    -- Added the following new functions:
    	sin(X)		sine of X
    	cos(X)		cosine of X
    	tan(X)		tangent of X
    	asin(X)		arc-sine (inverse sine) of X in range [-pi/2, pi/2],
    			for X in range [-1, 1]
    	asin(X)		arc-cosine (inverse cosine) of X in range [0, pi], for
    			X in range [-1, 1]
    	atan(X [, Y])	arc-tangent (inverse tangent) of X in range
    			[-pi/2, pi/2] if Y is not provided, or of Y/X in range
    			[-pi, pi] is Y is provided
    	sinh(X)		hyperbolic sine of X
    	cosh(X)		hyperbolic cosine of X
    	tanh(X)		hyperbolic tangent of X
    	exp(X)		exponential function e^X
    	log(X)		natural logarithm ln(X), for X > 0
    	log10(X)	base 10 logarithm of X, for X > 0
    	ceil(X)		smallest integer not less than X, as a floating-point
    			number
    	floor(X)	largest integer not greater than X, as a floating-point
    			number
       All of these functions take only floating-point arguments and return
       floating-point results.  They raise E_INVARG if their argument is out of
       range or E_FLOAT if the result overflows.  On underflow, they return zero.
       [Incredibly, some systems also print an error message on standard error if
       the argument is out of range; there isn't anything I can do to stop it, so
       just ignore such messages in the log.]
       (This ends the floating-point changes.)
    -- Changed the function `random()' to allow calls with no arguments; this is
       effectively the same as passing in the largest MOO integer.
    -- Fixed a long-neglected loophole in tick-counting; the following constructs
       all newly take one tick now:
    	-- exception-handling expression: `expr ! codes'
    	-- exception-handling statement: try ... except (expr) ... endtry
    	-- cleanup statement: try ... finally ... endtry
    	-- scattering assignment: {A, B, @C} = X
    -- Fixed a bug in the decompiler that could panic the server if a WHILE loop
       was the first thing inside the ELSE part of an IF statement.  (Thanks to Ron
       Stanions for reporting this.)
    -- Added documentation of what's required in order to add a new MOO value type
       to the server; see the new file AddingNewMOOTypes.txt.
    -------------------------------------------------------------------------------