The general solution to error handling is actually quite simple.  I have
thought about adding it, but never got around to it.

  1. A new sub-type of int would be created called ERROR.
  2. A new predicate function would exist called errorp().
  3. All efuns would return an int/error svalue when an error is
     detected during efun processing.
  4. A new mudlib-imported error.h file would exist to define error
     numbers in terms of #defines (the #defines would be used in both
     the driver and mudlib code)
  5. A function (call it perror()) would exist that accepted an error
     wvalue and returned a printable string.
  6. All efuns would be converted to use these new error svalues and
     associated numbers.

All mudlib code that did things that could error out would either:

  data = efun(..);
  if (!data-type-expectedp(data))
    return;

or:

  data = efun(..);
  if (errorp(data))
    return;

return would be replaced with whatever error recovery action would need to
take place in that context.  Errors could then be trated in an integrated
fashion throughout the driver/mudlib.

        Cygnus

--

we need to made a single-user option for MudOS that doesn't use sockets
at all so that people wanting to run MudOS at schools where programs
aren't allowed to listen on socket (anti-mud policies) can use MudOS
for developing LPC code for another mud.

--john

--

We came up with hopefully a somewhat useful idea to add_action() efun.

Something like:   add_action( string, void|string|string *, void|int );

So that if you do  add_action( "look", ({ "look", "l", "glance" }) );
it will set 'look', 'i', and 'glance' as all possible commands to call
'look' function in the object.  This would shorten code so that you don't
have to do 3 different add_action calls.  What do you think?

Decker

--

From: John Garnett <garnett@gestalt.austin.tx.us>


It'd be cool if there were efuns like this:

mapping x;

attach_mapping(mapping x, string filename);

detach_mapping(x);

which would attach mapping x to the database named by filename.

any accesses to the mapping x would in fact manipulate the database.

This would work much the way attached mappings work in Perl.

We could use the dbm database code in UNIX(tm).  Only problem is
not all UNIX's have dbm's that support multiple databases per
UNIX process.

--

In message <9303080120.AA26940@rock.concert.net> Dank writes:
>powerful.  This seems "grossly unfair" to our more serious gamers.  That's
>why i need to know the best way to implement (either in the driver or in LPC)
>an hb_call_out() efun, that operates exactly as call_out() does, except that
>it calls its function after a set number of _heartbeats_ have elapsed, not
>after a set number of seconds.
>  I ran this by Mobydick, and he thought the solution should be sought from
>you driver folks rather than in the mudlib (course, that may be because
>he's a mudlib coder :)

I agree; it does seem that we need a variant of call_out that operates in terms
of number of heartbeats rather than absolute # of seconds.  A few ways
to do this.

// optionally change the way call_out() works so that muds can change it if
// they like.
#define CALL_OUT_UNITS_EQUAL_HEARTBEAT /* or some shorter similar thing */

Or we could make a call_out2() efun that operates in the desired heartbeat units
(name it something more appropriate than call_out2()).

--

1) Have the z command in the editor check the user's PAGER settings.
   ie: getenv("LINES")  much like the mudlib's more command does.  If there
   isn't any setting, you can have it default back to the standard z length.

--watcher

--

someone should add support for the telnet go-ahead (GA) thingie so
that clients can tell what is a prompt and what is not.

--john

-----

This is not precisely a bug.. if this is not the correct forum for this please
tell me.
Basically, I am wondering why master virtual objects (i.e. virtual objects not
created via new()) still have clonep==1.  It seems to me that they should not.
In one sense, the reason is obvious -- in simulate.c, the O_CLONE flag isn't
modified, thus it remains set.  I think virtual objects would behave more like
normal objects if simulate.c cleared this flag for virtual master objects.
The reason I'd like this is because as it stands now, objects can't distinguish
between:
 1) being a virtual object that was not created using new() (ie a "master")
 2) being a "clone" of a virtual object (an object "cloned" from a master
        virtual object)
I would find the ability to distinguish between these useful, but more
importantly I think it fits the conceptual model for the behavior of virtual
objects.
 
 - Does this make sense?
 - Is it a compat buster?
 
-----

Note  11  Badlegs      (Sat Sep 11)  MARKERS
 
When using markers within a list, you have to remember to start the line
after the marker with a comma. Could we possibly have it so that it
MARKERTEXT end in a comma or semicolon, that those characters are preserved
, so that
        ([ "sign" : @END,
<text>
END,
           "box" : @END,
 
would work. Also, if you try to do:
        string = @END
<text>
END
 
You have to remember to put a spare semicolon on the next line, which looks
silly. Please could we have a cure to this?
 
Badlegs@clootie

-----

From bobf Sun Oct  3 00:31:28 1993
Received: from actlab.rtf.utexas.edu by feenix.metronet.com with SMTP id AA22687
 
  (5.65c/feenix for <bobf@metronet.com>); Sun, 3 Oct 1993 05:31:48 -0500
Return-Path: <bobf>
Received: from feenix.metronet.com by actlab.rtf.utexas.edu (5.0/SMI-SVR4)
        id AA12770; Sun, 3 Oct 93 05:31:48 CDT
Received: by feenix.metronet.com id AA22661
  (5.65c/feenix for mudos-bugs@actlab.rtf.utexas.edu); Sun, 3 Oct 1993 05:31:28 
-0500
Date: Sun, 3 Oct 1993 05:31:28 -0500
From: Bob Farmer <bobf>
Message-Id: <199310031031.AA22661@feenix.metronet.com>
To: mudos-bugs@actlab.rtf.utexas.edu
Subject: save_object()
Content-Length: 109
 
hmm, save_object() should probably somehow save the subtype of numbers.
(ie null, undefined, error, etc)
 
bt

---

Note  17  Alexus       (Sun Oct  3)  config settings
 
Driver folks, how about a tool for showing wizards what all the current
config settings are?  (Or not all, just some useful ones, like what max_eval
is, etc.)
 
I'd write it, but I dunno how these settings are stored, and my time is
stretched to the limit anyways, haven't had much driver tinkering time.
 
- Al

---

file_length() efun that returns the number of lines in a file

---