Jenora's Basic Muf Help for Porting Programs

Jenora repeats for the log: "Let's do the basics. There are two ways to set up macros. Using a library, and built-in to the editor."

Jenora says, "The first, and oldest method is to use the editor. What you do is @edit a MUF program, any program, and then do
'def '
The macro is any word, and the definition can be as long as you can type in."

Copernicus purrs, "How do I find macros that a program uses?"

Jenora says, "While in the editor, you can do ' show' as well to list the macro, or say ' show' to list any macro beginning with . If there's no prefix at all, it lists all macros. 'Show' can be abbreviated to just 's', so just do 's' will list every macro built into the editor."

Jenora says, "These macros are all stored in a single file, I think game/data/muf/macros in the server directory."

Copernicus ohs and checks.

Jenora says, "As for how to find out what macros a program uses, the easiest way to do that is to compile the program and see if it chokes on some macro you haven't installed."

Copernicus ohs, "Boy, I've done a lot of that."

Copernicus purrs, "And transferring them is that easy?"

Jenora grins. "That or scan the program visually, though unless you're familiar with what MUF primitives exist that gets messy. Anyhow, any macro set up in the editor like that gets called as '.' in the program code. Also, all macros in the editor are available to all programs always.

Copernicus ahas, "Okie. Yep, that's got to be it then."

Jenora says, "To transfer a macro you'd have to use the 's' command to list it on a MUCK where it exists, then 'def' it on ths one."

Jenora says, "Now, on to libraries..."

Copernicus nods to Jenora.

Jenora says, "A library is simply a MUF program with some of its routines declared 'public'. It then has a series of _defs/ properties set on it."

Jenora says, "What happens is that any program can do '$include ', and all the _defs/ properties are loaded in as macros. The name of the property after _defs/ is the name of the macro, and the value of the property is what gets substituted in."

Jenora says, "The big advantage of them is because loading them in requres a command in the program, you can pick and choose what macros you want to use."

Copernicus purrs, "I'm a bit unclear. You're using macros and libraries as a synonym. Is that correct?"

Jenora says, "No, I'm not."

Jenora says, "Libraries contain macros. You pick a macro by picking the library that contains it."

Copernicus ahs, "So you can also pick a macro by calling it by name?"

Jenora says, "You have to do both. You do $include to make the macro available so you can use it, then you use it later in the program."

Copernicus ahas, "Very much like include files in C. Ok."

Jenora says, "As an example, do 'ex $jen/lib/version=_defs/'"

Jenora says, "Something like that, yes."

Copernicus purrs, "So what happens when I just port over a macro by doing the s and then def macro blah blah?"

Jenora says, "Anyhow, my version library has two macros defined on it. One is just 'version-funcs:"!|version" "version"', and pushes those two words onto the stack; the other is 'version-check:"$jen/func/version" match "int-version-check" call' which looks up the version program and then calls a subroutine within it. The latter is the main reason for setting up libraries."

Jenora says, "If you just port over a macro using 'def', then it's available for all programs, all the time. You just have to do '.' inside the program to use it."

Copernicus ahs, "So I won't necessarily have to port libraries over too. Good."

Jenora says, "Oh, I should say, there is in fact a third way of defining a macro, but it's more self-contained... you can do
'$define $enddef' within a program. Then that macro is only usable by that program, but because it's defined within the program itself you have no portability problems."

Jenora says, "When it comes right down to it, a macro is just a shorthand: a way to use a single word to specify an entire sequence of operations."