MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
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:
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.
-------------------------------------------------------------------------------
Follow-Ups:
Home |
Subject Index |
Thread Index