MOO-cows Mailing List Archive


ALPHA-TEST release of LambdaMOO version 1.8.0alpha6

I have made the next (and perhaps the last) *alpha-test* release of version
1.8.0 of the LambdaMOO server in the usual place:

This is still an ALPHA TEST release of the server and, although it's getting
more and more stable as time goes on, there are almost certainly some more
server-crashing, database-losing bugs remaining, so please DO NOT USE THIS

Please continue to send your bug reports to the main MOO-Cows mailing list.
I still expect to make at least one more test release before the final,
production-approved one, but I'm now hoping that that will be a `beta' release
(i.e., with no new major features to be added before final release).  We'll
see, though.

Here's the ChangeLog.txt entry for this release:
Version 1.8.0alpha6, 16 January 1996
-- Replaced panic with raising E_TYPE in the case where `x[$]' is applied to a
   non-string, non-list `x'.  (Thanks to Kipp the Kid for reporting this.)
-- Fixed (yet another) bug in the stack-unwinding code; this one stuck the
   return information for each of a built-in's second and subsequent verb calls
   on successively higher stack frames, causing all manner of havoc, the least
   of which was somewhat surprising results from the (correct!) callers()
   built-in.  (Thanks once again to Brian Buchanan for reporting this bug; this
   marks the *third* bug in stack-unwinding that Brian has uncovered!)
-- Changed the rules for binary strings slightly so that (a) TAB is no longer
   treated as a normal, printing character (i.e., it gets converted to `~011'
   on input in binary mode), and (b) `~' is treated just like all of the
   non-printing characters (i.e., it gets converted to `~176' on input in
   binary mode and the sequence `~~' is illegal in binary strings).  Change (a)
   removes one more source of TAB characters from the MOO (which can only be a
   good thing), and change (b) both simplifies the specification and makes it
   easier to compute the true length of a binary string (i.e., it's the length
   of the string itself minus three times the number of tildes).  (Thanks to
   James Deikun for these suggestions.)
-- Fixed uninitialized-variable bug in the `program' command in emergency
   wizard mode.  (Thanks to Kipp the Kid for reporting it.)
-- Fixed potential memory smash bug if #100 (or #200 or #400 or #800 or ...)
   was a recycled object in the DB file being loaded.  (Thanks to Dave Van
   Buren for sending me a DB file that tickled the bug and to Purify for
   pinpointing it.)
-- Fixed bug that caused *all* settings of the .wizard property to be logged,
   instead of just those that set it to a true value.  (Thanks again to Dave
   Van Buren for reporting this.)
-- Fixed bug accuracy of the top line number in tracebacks resulting from the
   setting of a wizard bit.  (Thanks one last time to DVB for sending me a
   traceback that contained such an error.)
-- Added new built-in function `function_info([NAME])' which returns
   descriptions of built-in functions available on the server.  If NAME is
   provided, only the description of the function with that name is returned;
   if NAME is omitted, a list of descriptions is returned, one for each
   function available on the server.  Each description is a list of the
   following form:
   NAME is the name of the built-in function, MIN_ARGS is the minimum number of
   arguments that must be provided to the function, MAX_ARGS is the maximum
   number of arguments that can be provided to the function or -1 if there is
   no maximum, and TYPES is a list of MAX_ARGS numbers (or MIN_ARGS if MAX_ARGS
   is -1), each of which represents the type of argument required in the
   corresponding position.  Each type number is as would be returned from the
   typeof() built-in function except that -1 indicates that any type of value
   is acceptable.  For example, here are several entries from the list:
	{"listdelete", 2, 2, {4, 0}}
	{"suspend", 0, 1, {0}}
	{"server_log", 1, 2, {2, -1}}
	{"tostr", 0, -1, {}}
   `listdelete()' takes exactly 2 arguments, of which the first must be a list
   (LIST == 4) and the second must be a number (NUM == 0).  `suspend()' has one
   optional argument that, if provided, must be a number.  `server_log()' has
   one required argument that must be a string (STR == 2) and one optional
   argument that, if provided, may be of any type.  `tostr()' takes any number
   of arguments and it can't be determined from this description which argument
   types would be acceptable in which positions.
      It should be noted that, in a feat of synchronicity, this new built-in
   brings the total number supported in the official server release to exactly
   100!  (Thanks to some-user-whose-message-I've-lost [feel free to mail me
   again so that I can patch this thank-you note] for suggesting such a
   built-in function.)
-- Fixed the definitions of the built-in functions match(), rmatch(), index(),
   rindex(), and strsub() to accept any type of value for their final,
   `case-matters' flag argument.  Also fixed `verb_code()' to allow any type of
   value for either of its final two flag arguments.
-- Added `scattering assignment' expression, allowing the elements of a list to
   be spread among multiple variables simultaneously; this could be used, for
   example, to get at the arguments to a verb in a more convenient form than
   the list `args'.
      A scattering assignment expression looks like this:
   where TARGETS is a comma-separated list of places to store elements of the
   list that results from evaluating EXPR.  A target has one of the following
	    This is the simplest target, just a simple variable; the list
	    element in the corresponding position is assigned to the variable.
	    I call this a `required' target, since the assignment is required
	    to put one of the list elements into the variable.
	    I call this an `optional' target, since it doesn't always get
	    assigned an element.  If there are any list elements left over
	    after all of the required targets (and all of the other optionals
	    to the left of this one) have been accounted for, then this
	    variable is treated like a required one and the list element in the
	    corresponding position is assigned to the variable.  If there
	    aren't enough elements to assign one to this target, then no
	    assignment is made to this variable, leaving it with whatever its
	    previous value was.
	    This is also an optional target, but if there aren't enough list
	    elements available to assign one to this target, the result of
	    evaluating EXPR is assigned to it instead.  Thus, EXPR is a kind of
	    `default value' for the variable.  The default value expressions
	    are evaluated and assigned working from left to right *after* all
	    of the other assignments have been performed.
	    Analogously to MOO argument lists, this variable is assigned a list
	    of all of the `leftover' list elements in this part of the list
	    after all of the other targets have been filled in.  It will be
	    assigned the empty list, if there aren't any elements left over.  I
	    call this a `rest' target, since it gets the rest of the elements.
	    There may be at most one rest target in TARGETS.
   If there aren't enough list elements to fill all of the required targets, or
   if there are more than enough to fill all of the required and optional
   targets but there isn't a rest target to take the leftover ones, then E_ARGS
   is raised.
      Here are some examples of how this works.  Assume first that the verb
   `me:foo()' contains the following code:
		b = c = e = 17;
		{a, ?b, ?c = 8, @d, ?e = 9, f} = args;
		return {a, b, c, d, e, f};
   Then the following calls return the given values:
	    `me:foo(1) ! ANY'              => E_ARGS
	    me:foo(1, 2)                   => {1, 17, 8, {}, 9, 2}
	    me:foo(1, 2, 3)		   => {1, 2, 8, {}, 9, 3}
	    me:foo(1, 2, 3, 4)		   => {1, 2, 3, {}, 9, 4}
	    me:foo(1, 2, 3, 4, 5)	   => {1, 2, 3, {}, 4, 5}
	    me:foo(1, 2, 3, 4, 5, 6)	   => {1, 2, 3, {4}, 5, 6}
	    me:foo(1, 2, 3, 4, 5, 6, 7)	   => {1, 2, 3, {4, 5}, 6, 7}
	    me:foo(1, 2, 3, 4, 5, 6, 7, 8) => {1, 2, 3, {4, 5, 6}, 7, 8}
   Finally MOO has a convenient mechanism for naming verb arguments, checking
   for there being exactly the right number of arguments, handling optional and
   `rest' arguments, etc.  I intend to start every new MOO verb of mine with a
   scattering assignment of `args', and I encourage other MOO programmers to do
   the same.


Home | Subject Index | Thread Index