[Prev][Next][Index][Thread]

# LPMOO FAQ 9/17/95

- Date: Sun, 17 Sep 1995 20:26:11 PDT
- From:
- Content-Type: text/plain; charset="us-ascii"

    Due to recent increased interest in LPMOO, I decided compiling a FAQ might
    be a good idea.  So here it is :)
    This is my first attempt at creating a FAQ, so if you have any suggestions
    or additions, please feel free to send them to me.

    Matt Pauker
    ---------------------------------

                                              LPMOO FAQ
                                       Compiled by Matt Pauker
                                        Last updated 9/17/95

    General
    ________________________________________________________________________________

    Q: What is LPMOO?

    LPMOO is an implementation of MOO built on top of a server called DGD.  It
    is completely compatible with LambdaMOO 1.7.8, although some differences do
    exist (See LPMOO vs. LambdaMOO).

    Q: What is DGD?

    DGD, which stands for Dworkin's Generic Driver, is a portable, small,
    efficient network server.  LPMOO runs on top of DGD.

    Q: Where can I get LPMOO?

    The most recent version of LPMOO, 1.2, is available at:

    ftp://ftp.ccs.neu.edu/pub/mud/servers/lpmoo/lpmoo-1.2.tar.gz

    In addition to the LPMOO server, you will need a LambdaMOO-format DB.  If
    you're starting fresh, you'll probably want:

    ftp://ftp.ccs.neu.edu/pub/mud/servers/lpmoo/LambdaCore-1Oct94-sans-spell.db.gz

    That is a fresh copy of the Oct '94 LambdaCore, with the exception of
    $spell, which is missing from the DB.  $spell was removed because it
    significantly increases bootstrap time, and is not often used.  If you
    really need spell, FTP it from ftp.parc.xerox.com.

    Q: Who wrote LPMOO?

    LPMOO is written and supported by Robert Leslie (rob@ccs.neu.edu).  You can
    often find him on MirrorMOO (mirror.ccs.neu.edu 8889) as Verement.

    LPMOO vs. LambdaMOO
    ________________________________________________________________________________

    Q: What are the differences between LPMOO and LambdaMOO?

    >From the LPMOO docs:

    Important differences between LambdaMOO 1.7.8 and LPMOO 1.2:

     - LPMOO supports three additional datatypes: floats, tables, and buffers.

     - Task execution limits are in DGD terms; no attempt is made to simulate
       tick or seconds counting. {ticks,seconds}_left() are approximate.

     - Background tasks receive equal "tick store" as foreground tasks.

     - fork (0) and suspend(0) are always translated into fork (1) and suspend(1).

     - clear_property() returns E_INVARG for all builtin properties.

     - ob.wizard = x will only affect future tasks, not any existing (suspended
       or forked) ones.

     - Suspended tasks are not saved across cold restarts (bootstrapping from
       a LambdaMOO-format DB file).

     - Suspended tasks _are_ saved across warm restarts (using a binary state
       dump), however their starting times will be relative to the time of the
       state dump.

     - open_network_connection() will suspend until the connection either
       succeeds or fails.

     - It is not illegal to use a string value for `obj' in obj:verb(@args); this
       is interpreted as a function call in the LPC object named by `obj'.

     - Strings and lists are not unlimited in size. Strings and lists are limited
       to approximately 64K characters and elements, respectively. Attempts to
       exceed these limits will result in a run-time traceback error.

     - The number of pending forked (or suspended) tasks is not unlimited. The
       limit is determined by the value of the `call_outs' setting in the dgd.cf
       configuration file. Attempts to exceed the limit will yield a traceback.

     - $server_options is not (yet) supported.

     - disassemble() is functional, but does not return any useful information.

     - The .program builtin verb is not functional.

     - Esoteric expressions such as:  a = {1, 2}; a[1] = (a = 0);  do not behave
       as they do in LambdaMOO. Expressions such as:  a[1] = a[2] = 3;  behave
       as you would expect. These are technically incorrect simulations of MOO,
       but are more intuitive and actually simpler to implement.

     - If $dump_interval is negative, automatic checkpoints are never made (under
       the assumption the db is handling them.)

    Q: What are some advantages of LPMOO over LambdaMOO?

     - Disk-based operation.  Objects which have not been used recently are swapped
       out, and therefore do not use RAM.

     - Table, buffer, and floating point support.  (See below for descriptions of
       tables and buffers.)

     - Access to LPC, a low-level language.  LPC can be used to implement very
       efficient code that can be called from MOO.

     - Binary dump files allow for quick checkpoints.

     - Multi-port listening.

    Q: What are some disadvantages of LPMOO as compared to LambdaMOO?

     - Binary dump files are much larger than text dump files.

     - With a small DB, LPMOO experiences a bit more lag than LambdaMOO, although it
       uses less RAM.  Larger DBs have not been tested.

    New Datatypes
    ________________________________________________________________________________

    Q: How do I use floats?

    Floats (Floating-point numbers) are used exactly like integers.  If you
    want to have a float returned by an operator (e.g. +,-,*,/), one or both of
    the numbers on which you are operating must be a float.  For more specific
    information, see doc/floats in the LPMOO distribution.

    Q: What are tables?

    Tables are lists which can be indexed by any MOO value.  Tables are also
    sometimes called associative arrays, mappings, or dictionaries in other
    languages.  For more specific information, see doc/tables in the LPMOO
    distribution.

    Q: How would I use tables?

    Tables are useful for a wide variety of tasks.  Once you start using
    tables, you'll see hundreds of possibilities for using them.  Also, they're
    more efficient than using lists.
    One of the best uses of tables is for the replacement of synchronized lists
    - In other words, a group of properties which each contain lists, with each
    element corresponding to every other element with that same index.  For
    example, if I have:

    #100.people == {"Bob", "Joe", "Ann", "Fred"}
    #100.ages   == {25, 39, 19, 32}

    (Where Bob's age is 25, Joe's age is 39, etc.)

    I could replace that with a table:

    #100.people == {"Bob" ~ 25, "Joe" ~ 39, "Ann" ~ 19, "Fred" ~ 32}

    This table makes the ages much easier to access.  Rather than having to do:

    age = #100.ages["Joe" in #100.people];

    I can do:

    age = #100.people["Joe"];

    Not only is this easier to type, but it is much more intuitive.

    Also, if you wanted to see if you could get Joe's age (i.e. "Joe' is in the
    table), you would check:

    if ("Joe" in #100.people)

    This is very similar to the use of the 'in' operator in checking for an
    element in a list; however, using the 'in' operator with a table only
    returns 1 if the element exists in the table, and 0 if it doesn't (Since an
    element in a table doesn't have a numerical index as a list element does.)

    This is only one possible use of tables.  Experiment and you'll find many more.

    Q: What are buffers?

    Buffers are containers for arbitrary blocks of binary data - In other
    words, a series of ASCII values.  For example, the word "Hello" could be
    represented as:

    [72, 101, 108, 108, 111]

    For more specific information on buffers, see doc/buffers in the LPMOO
    distribution.

    Q: How would I use buffers?

    Buffers are most useful for sending ASCII control codes (Characters with
    ASCII values < 32) to users.  The most common example is sending ANSI codes
    to users to display color.  For example, to display the word "Hello" in
    bold, you might send the following buffer (Using notify()) to the user:

    [27, 91, 49, 109, 72, 101, 108, 108, 111]

    Remember, though, that when you send a buffer to the user using notify(), a
    newline is *not* appended.  Therefore, you would want to send this buffer
    to the user like this:

    notify(this, [27, 91, 49, 109, 72, 101, 108, 108, 111]);
    notify(this, "");

    The second notify() will send the newline to the user.

    Multi-Port Listening (MPL)
    ________________________________________________________________________________

    Q: What is Multi-Port Listening and what does it do?

    Multi-Port Listening allows your LPMOO to accept connections on multiple
    ports.  By default, LPMOO listenings to two ports: A telnet port and a
    binary port.

    Q: How do I activate Multi-Port listening?

    In etc/moo.cf, set mport_listening to YES.  However, before you do this,
    you must start up the server without Multi-Port listening, and set the last
    three lines of #0:server_started to:

    status = dgd_status();
    listen(status[23],#0,"telnet");
    listen(status[24],#0,"binary");

    That will make LPMOO listen to the telnet and binary ports (As specified in
    etc/dgd.cf) when it starts up.

    After adding those lines, shutdown the MOO, set mport_listening to YES, and
    start it back up.

    Q: How do I use Multi-Port listening to listen to an extra port?

    To listen() to a port, you must have a verb called :do_login_command() that
    will handle connections on that port.  So to listen to port 6789 and have
    its input handled by #100:do_login_command, you would execute:

    listen(6789,#100);

    For most purposes, you will want the port to handle binary connections.  If
    you don't specify a third argument, it is automatically assumed to handle
    binary connections.  If you specify "telnet" as the third argument, the
    port will only handle telnet connections.

    Q: What are some uses of MPL?

    MPL could be used for a variety of reasons, but probably the most common
    function for which it would be useful is for creating a WWW interface for a
    MOO.  Using MPL, you can specify a port that is solely used for WWW
    accesses, and handle all input/output through one object.
    Other possible uses might be setting up a gateway between two MOOs,
    creating a gopher server, or making an interface for a specialized client.

    LPC
    ________________________________________________________________________________

    Q: What is LPC?

    LPC is a low-level language used by DGD.  It is very similar to C, although
    some differences exist.  Explaining the specifics of LPC would be far
    beyond the scope of this FAQ.  Unfortunately, there is no complete
    documentation written for LPC.  The best way to learn is probably to take a
    look at the LPC files distributed with LPMOO, in the mudlib/lpc/ directory.

    Q: Why use LPC?

    Writing code in LPC is more efficient than writing it in MOO, as the
    LPC->MOO converter, like all converters, doesn't do as good a job as a
    human.  Also, because LPC is a lower-level language than MOO (In the LPMOO
    sense), it opens many more possibilities.

    Q: How do I write LPC code to use in MOO?

    Writing LPC code for use in MOO involves a number of steps.  You first need
    to write the LPC code in a textfile (Which must have a name ending in .c),
    and place that textfile in the mudlib/ directory.  Then, from MOO, type:

    ;"/lpc/utils":update(<DGD path to object>)

    Where <DGD path to object> is the path to the textfile within the mudlib
    directory, minus the ".c".  For example, if your file's path is
    mudlib/lpc/test.c, then the DGD path to that object is "/lpc/test".

    If you think this is complicated and a lot of work, you're right.
    Fortunately, Rob Leslie has created a File Editor (A slightly modified
    Generic Editor) which makes it very easy to create LPC code.  If you'd like
    to get the File Editor, along with some other similar commands, go to
    MirrorMOO (mirror.ccs.neu.edu 8889) and ask Verement to help you get them.

    Once you've written the LPC code, you can call a function in that file as
    if it were a verb.  For example, if you have a function called "hello" in
    test.c, you would call it like this:

    "/lpc/test":hello()

    (Passing the appropriate arguments within the parenthesis.)

    Troubleshooting
    ________________________________________________________________________________

    Problem: The server isn't responding to user commands quickly enough.

    >From the LPMOO docs:

    You can increase response time by reducing the number of objects being
    swapped out every second. The `swap_fragment' option in the etc/dgd.cf
    configuration file specifies what fraction of all objects to swap out. For
    example, a value of 32 means that 1/32 of all objects are swapped out every
    second.

    By making this value larger, you decrease the number of objects forced to
    be swapped out each second, and therefore increase normal response time.
    Good values to try would be 64 or 128. Note, however, that fewer objects
    swapped out means the process will use more memory.

    Problem: The server is using too much RAM.

    >From the LPMOO docs:

    You can change DGD to be more aggressive at swapping out unused objects to
    disk, thereby reducing the overall process size. The `swap_fragment' option
    in the etc/dgd.cf configuration file specifies what fraction of all objects
    to swap out each second. For example, a value of 32 means that 1/32 of all
    objects are swapped out every second.

    By making this value smaller, you force more objects to be swapped out each
    second. Note, however, that the more time DGD spends swapping objects out
    to disk (and later back in), the slower its perceived response time will
    be.

    Problem: The server isn't accepting incoming connections.

    >From the LPMOO docs:

    If you've enabled the `mport_listening' option in moo.cf, the server will
    NOT automatically open and listen on any network ports. Your database is
    expected to do this itself via the listen() builtin, typically from the
    #0:server_started verb.

    To use the mport_listening feature, first disable it and start the server.
    Connect and modify #0:server_started as described in the documentation for
    the listen() function. Shutdown, re-enable mport_listening, and restart.

    Problem: Evaluating an expression that returns a table returns "{table}".

    This occurs because $string_utils:print() doesn't know what a table is, so
    it turns it into a string, using tostr(), which gives you "{table}".

    The easy way to fix this is to set the first line of $string_utils:print() to:

    return toliteral(args[1]);

    The toliteral() builtin will return a string form of its argument that is
    more readable.

    These are some more common problems you may encounter with LPMOO.  Other,
    more obscure problems are listed in doc/troubleshooting.  Also realize that
    these are only LPMOO-specific problems - For general MOO problems, you
    might want to check the MOO-Cows FAQ.

    List of LPMOO's
    ________________________________________________________________________________

                                            Ports
    MOO Name     Site                  Telnet   Binary   Comments

    MirrorMOO    mirror.ccs.neu.edu    8889     9990     Home of LPMOO
    HoloMOO      shu.isisnet.com       1701     6666     Star Trek Role-Playing

    If you have any additions to this list, please send them to
    mpauker@peganet.com.  Include your MOO's name, site, telnet & binary ports,
    and a *short* comment.

    ________________________________________________________________________________

    The LPMOO FAQ is maintained by Matt Pauker (mpauker@peganet.com).  If you
    have any comments, questions, suggestions, or additions, please mail him.
    This FAQ will be updated as changes warrant.
    Matt Pauker makes no warranty as to the validity of this information.

- Prev: Re: LPMOO [LPMOO]
- Next: LPMOO general query
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index