HUH?!?
Mark A. Heilpern wrote:
> I'm in the middle stages of building in C interpretation for CircleMUD...
> I'm not ready to release it to the public yet but it is ready for limited
> beta testing. I've included current documentation for it below; if anyone
> is interested in checking it out, I'll make a tar.gz of the patch and some
> support files for it.
>
> CircleMUD C Interpreter documentation and integration by Mark Heilpern
>
> The C Interpreter is an extension to your mud's command language that
> provides a -very- rudimentary C understanding for functions that can
> be made to execute. I did not write the interpreter; rather it was once
> part of a Macintosh terminal emulation package, and it was a part of
> something unknown prior to that. As far as I know, there are no copyright
> issues with this code.
>
> Some of the limitations to the C interpretation are listed here. This list
> is NOT comprehensive.
> * No structures
> * No #define/#ifdef/#include/#<what-so-evers>
> (#include could be made to function relatively simply)
> * No "do {...} while()" control structure. "while() {}" DOES exist.
> * No enumerations
>
> MAJOR LIMITATION:
> * A function that does something like "while (1);" WILL lock your mud
> up cold. Coder-beware!
> * There is currently a hardcoded maximum size of 16k for the script
> data (between two source files).
>
> To call the interpreter, an implementor simply issues the "interp" command
> at the CircleMUD prompt. This will cause one or two files to be read:
> lib/misc/cfuncs.s and lib/plrfuncs/<path to player-name.s> if the latter
> exists. (cfuncs.s must exist). Then, the main() subroutine will be run.
> The order of the reading of these files allows main() in the player-
> specific file to override the cfuncs.s/main() routine.
>
> Alternately, the name of an entry subroutine may be placed on the mud
> commandline, such as "interp test".
>
> One caveat: all valid function entrypoints (main, or any other function to
> be started from the command line) must be defined without any parameters
> or return type.
>
> Here are the current build-in functios for the interpreter:
> ** C library routines:
> printf, sprintf, free, itoa, malloc, puts, stack, strcat, strcmp,
> strcpy, atoi
> ** CircleMUD intrinsics:
> system, get_char_vis, send_to_char
> ** Non-standard CircleMUD functions:
> active_ch, first_descriptor, next_descriptor, first_character,
> next_character
> ** utils.h macro access:
> GET_NAME, GET_TITLE, GET_LEVEL
>
> Adding more built-in's is relatively simple. There is a table for them
> at the bottom of intrinsics.c.
>
> Documentation for built-ins that are not blindingly obvious:
> stack(): output interpreter stach utilization info
> system(char *): the character string enclosed will be sent to
> command_interpeter() on behalf of the char running the function.
> active_ch(): return (as an int) the char_data * of the character
> running the function.
> first_descriptor()/first_character(): return (as an int) the global
> descriptor_list or character_list, as appropriate.
> next_descriptor(int)/next_character(int): taking as input the pointer to
> a char_data or descriptor_data (expressed as an int), return the ->next
> element
>
> +------------------------------------------------------------+
> | Ensure that you have read the CircleMUD Mailing List FAQ: |
> | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
> +------------------------------------------------------------+
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST