What might be wrong with the idea of adding an optional 2nd argument to catch() which would cause any errors caught NOT to be logged to debug.log? One place I want to have a catch(<expr>,1); is in the 'update' command...after all, a zillion: caught: Error in loading object program: cmds/object/_update.c, object: cmds/object/_update line 125 ' cmd_hook' in ' std/user.c' (' std/user#225')line 94 ' cmd_update' in 'cmds/object/_update.c' (' cmds/object/_update')line 125 ' CATCH' in 'cmds/object/_update.c' (' cmds/object/_update')line 125 certainly doesn't help much does it? A brief browse in simulate.c and interpret.c indicates to me that it shouldn't be too hard or expensive a modification. Is it? --Tensor@5thDimension|LPCC -- lemay@staff.tc.umn.edu (Lawrence LeMay) writes: > The Amylaar parser also contains a new efun called > replace-program(). basically, this allows you to write a > master-object that inherits ONE file, such as a typical room, and > by adding the replace_program("room/room"), you alter the object > into essentially a clone. the filename stays the same, but the > program space for this master object is discarded, and is replaced > with a link to the program space of the inherited object. The space > used by each variable is also reduced to that of a clone. I'm not > explaining this very well, but you can read the Tubmud (Amylaar > parser) LPC Manual for more information... -- 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()). -- o : (admin) >From : Archimedes Date : Fri Feb 26 16:30:50 1993 Subject: driver improvement ------------------------------------------------------------------------------ I was looking at urimud2.3. They have removed the slow linked lists of sentences. They hash the action verbs for each user instead of searching a linked list. We could probably implement it into MudOS for a vast parsing speed improvement. -- 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? -----