MOO-cows Mailing List Archive


BETA-TEST release of LambdaMOO version 1.8.0beta1

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

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

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!


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
-- 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)
   This behaves exactly like the statement
		WHILE (id = (expression))
   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");
		    if (!x)
		      x = 1;
		      notify(player, "continuing");
		    x = x + 1;
		    notify(player, "finally");
		  notify(player, "after");
		  if (x > 1)
		notify(player, "done");
   This verb produces the following output:
   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
-- 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 <> 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
-- 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
-- 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
-- Floating-point numbers not equal to 0.0 are treated as `true' in MOO
-- 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 + 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
	floor(X)	largest integer not greater than X, as a floating-point
   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.


Home | Subject Index | Thread Index