Hi,
Having long had a custom scripting system implemented, I am seeking a method
of enabling lower-level access using some form of interpreted language to
provide an extension to the scripting system without cluttering it with
millions of poorly integrated commands. I see them as subroutines or "black
boxes" that scripts call to perform various actions.
To this end I've done the following:
1) Created the SUBEDIT OLC. Supports the necessary flags (disabled,
debugged, approved, compiled) and tracking features (last editor, last edit
time, original author) The scripts are stored in categories, and can be
searched, etc. Basically a library where subroutines may be perused by
builders looking to create something with their script that cannot be easily
done in the scripting language itself.
2) Created the SUBROUTINE command. Lets you call subroutines in your scripts
by number.
3) Rooms/objs/chars have a set of variables they can allocate/deallocate
that are presented in the subroutine interpreter so as to provide command
arguments or provide a place to return information. The subroutine
description would clearly document which variables were used in the
particular subroutine.
4) Implemented a simple C parser by porting one originally written by
Herbert Schildt. Found that it was too limited for what I need. I could add
the features myself, but it would take a sizable time investment. Given the
limitations, I figured I'd look around and see what else was out there.
(structure support, array support, some pointer support, an update of the
return function, etc.)
Has anyone used the AE (application executive) code written by a Brian
Bliss? The reason I ask is that it seems to have a fairly steep learning
curve i.e. no docs that I could find and it hasn't been ported to anything I
have access to.. On the other hand, various references on the net have given
it good marks as an embedded language. It seems to have been written with
the idea of using the rest of the data in the program it's embedded in
fairly easily, the ability to present debugging information and a fairly
complete C implementation.
The AE and other languages can be found here:
http://www.idiom.com/free-compilers/.
Yahoo and others have good references to a lot of languages as well. From a
few day's worth of poking around I am left in a bit of a quandary. It seems
that there are many choices, all of them flawed in one way or another.
My ideal setup would be to create a transparent division between the
interpreter and the actual code. The idea is to be able to cut/paste the
code out of the mud and into a .c file and recompile, making an interpreted
subroutine a compiled one after it's been debugged and has become used
enough to warrant the work. (In this case the address of the function is
stored in the table, rather than the address of the string.)
Any suggestions? (Don't say LPC .. I tried it.. I found it very confusing..
it'd be a very long time before I could whittle out the parts I want and
would probably end up with a huge bloated hack that I woudn't ever fully
understand.)
In addition, TCL seems to get a lot of mention. Anyone care to take the time
to give the 'in a nutshell' evaluation of TCL as pertains to muds?
Thanks in advance for your time,
--Mallory
+------------------------------------------------------------+
| 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