| Repository | https://github.com/wrog/lambdamoo open issues here |
|---|---|
| Distribution | https://wrog.net/moo/dist/LambdaMOO-1.9.0alpha.tar.gz |
| (signature, github key) | |
| latest README | README |
| ChangeLog.txt |
ChangeLog.txt(Yes, this file is upside down, sorry. |
autoconf. (Thus far, we have tested against 2.68-2.72 — I'm guessing anything in the (current) 2.50 generation will work, though I'd be interested to know just how far back we actually go)../configure to select options and extensions from that command line. (Also self-identifying builds that tell you what you selected.)VPATH builds, for doing multiple simultaneous builds of different variants in separate directories simultaneously, are now doable.So far, we appear to be able to build and pass basic smoke tests on the following platforms:
Obviously, I would love to expand this list, especially if your favorite platform is not on there (e.g., a more recent Apple would be nice).
For this release, the goal is to be a "drop-in" replacement, something with roughly the same functionality, allowing for bug-fixes (with admittedly generous interpretations of what exactly counts as a "bug fix"), that can cleanly build on modern hardware / operating system toolchains,
so that your MOO instance can run essentially as before (assuming any variant(s) you were running are on The List that got merged in, and you use the right ./configure arguments).
(various other improvements, e.g., in database file format, networking, the programming language, and general usability, are on the table, but mostly being deferred to 1.9.1 and beyond. Current goal is to set things up so that we can have a "1.9.1 and beyond")
A secondary goal, given the apparent recent uptick of interest in MOO, is to provide those of you more recently coming to the party something to play with. Which you could do with this release. But for now, I'm more trying to get feedback on lower-level issues, hacking, building, i.e., getting back to the state where we have something that can actually be worked on... (tldr: It's possible you'll be happier waiting for "1.9.1 and beyond". Also:
Caution
by "play with" I mean run it strictly
-a localhostor at most on a local intranet or VPN limited to people you know or otherwise get along with. If what you want is to start a new public instance, not only is this release not really the time, but you will need more than just a server executable. There is also the matter of having a core database, a hosting environment, and there would also be administration, moderation, and security issues to consider. I don't have enough bandwidth to write that handbook right now (and I may not be the right person for it, either).
So, this is an "alpha" release. (Wikipedia suggests my usage of this terminology is a bit warped; I am apparently Old School or something: "alpha" to me means it's feature complete, builds, and vaguely seems to work, but there's more testing to do. "beta" will mean better docs and an actual test suite.)
Also the documentation is not exactly complete, meaning expect inadequacy in places, maybe some outright lies, or just not saying what it needs to, ... and we need to find those places (and which ones you focus on will tell me something about priorities).
There is no 1.9.0 Programmers Manual, yet. Then again, for 1.9.0, the user-level changes aren't going to be that significant (at least not for the non-Unicode server).
For now, use the github repository to open issues.
Find lies, or missing/inadequate explanations for things you want to know about that don't make sense, etc...
(Probably not totally critical right now, but (1) it might give you a better sense of what the framework actually does and (2) eventually someone other from me may want to write actual code...)
If your favorite platform is not one of the ones listed above and your attempt to build succeeds (or not!), I'd definitely like to hear from you. As you can see, my coverage of systems outside of Linux/amd64 is rather limited.
(I'd especially like to hear from you if you once-upon-a-time ran an actual instance but gave up on it because you got tired of fighting the ancient ./configure or were screwed by an OS upgrade.)
Try the tarball build, make distclean, then try it again.
Try the git build, make gitclean, and try that again.
Try a VPATH build from either one.
(yes, the README refers to a test suite; still a work in progress. So, unfortunately, this is not yet organized to be convenient. That's what the beta release is going to be if all goes well.)
Here is a quick convenience command you can set up (assumes you built in the source directory; modify to taste if you haven't):
$ mooval() {
printf "%s\n" ";$1" 'abort' |
./moo -e -l /dev/null Minimal.db /dev/null |
sed -e '0,/^[*]/d;/^MOO.*Bye.*NOT saving/,$d;/^$/d'
}
Cut&pasting everything after the $ is probably your best bet here. (See the Extensions tutoral, about 50 lines down for more about what this does or if shell functions are otherwise new to you.)
Then
$ mooval '"Hello world."'
MOO (#3): => "Hello world."
And then, if you have other favorite MOO code expressions that will work from emergency mode (essentially, anything that works in Minimal.db and doesn't need to suspend() is fair game), you can try those too.
A more sophisticated version of this would be
$ MOOSRC=/path/to/src
$ MOOBLD=/path/to/build
$ moodo () {
{ printf ";;\n"
if test $# -gt 0 ; then cat "$@"; else cat - ; fi
printf "%s\n" '' '.' 'abort'
} | $MOOBLD/moo -e -l /dev/null $MOOSRC/Minimal.db /dev/null |
sed -e '0,/^MOO (.*): Type one or more lines of code/ d' \
-e '/^MOO (.*): Bye. (NOT saving database)/,$d;/^$/d'
}
which lets you set MOOBLD if you have different build directories
and then takes either a list of filename arguments or nothing,
meaning either the contents of those files or stdin, respectively,
and then runs that:
$ moodo
notify(player,"hey");
return 42;
^D
#3 <- hey
=> 42
(note that this will not be like a usual MOO session that responds to single lines immediately).
In what follows,
./moo-old is whatever incantation you have to run your old 1.8.3
vintage executable or variant thereof, and
./moo is the new 1.9.0 version that you just built, presumably
with the correct ./configure arguments to mimic your old executable
(see README to find out what these are -- although this is also
not a completely bad way to check if you got the arguments right).
Two things:
When running ./moo-old in emergency mode, make sure you don't do
any ^D in the middle of a line, and make sure to always cleanly end
your session with quit,abort, or continue, because it is so
very easy to accidentally send 1.8.3 emergency mode into an infinite
death loop.
The -e is super-important; if you leave that out it'll be
immediately launching the listener + accepting connections /etc,
and we don't want that here.
$ ./moo-old -e Precious.db Junk1.db
...
MOO (#n): quit
Bye, saving database to Junk1.db
...
$ ./moo -e Precious.db Junk2.db
...
MOO (#n): ;;for p in (connected_players(1)) boot_player(p); endfor
=> 0
MOO (#n): quit
Bye, saving database to Junk2.db
...
$ diff Junk1.db Junk2.db && echo yay
I.e., the two files should be identical. This succeeding means the new server has the same capability as the old one of reading Precious.db and not losing or corrupting information (generally good to know).
Those with more time on their hands could instead not boot all of the connected players on the new-server run. Just quit out of it immediately, let it save Junk2.db directly, and then compare the list of connections there with what Precious.db originally had. Those being the same and the rest of Junk1.db and Junk2.db being identical will similarly be a win.
Admittedly, finding these lists requires some knowledge of DB format, but this particular task is easy: If there were n players on the list then it's the last n+1 lines of the file, looking something like:
n
active connections with listeners
player1 listener1
player2 listener2
...
If your old server executable doesn't work anymore, you can try this test, instead:
```
$ ./moo -e Precious.db Junk1.db
MOO (#n): quit
MOO (#n): Bye, saving database to Junk1.db
...
$ ./moo -e Junk1.db Junk2.db
MOO (#n): quit
MOO (#n): Bye, saving database to Junk2.db
...
$ diff Junk1.db Junk2.db && echo yay
```
which is less satisfactory because in this one, it's the new server doing both runs, and now all you're testing is that it can read back what it itself wrote, which is also good to know, but if anything is being lost between Precious.db and Junk1.db, we won't know without a detailed comparison.
This test suite from when I was first messing with network options back in 2003 has been updated a teentsy bit. It acid-tests certain specific features but is not in any way comprehensive.
If you install it in a grandchild directory, and you did a vanilla
build (i.e., not a VPATH build somewhere else), it should find
your moo executable and work out of the box. Otherwise you'll
need to edit its config.
If you're on Android or some other platform where basic network
functionality has been purposefully enshittified, you'll have
to poke around manually and then edit 1/config.
... though you can also feel free to skip / comment-out test #1 since it's testing network command-line args I haven't really touched in a long time that I'm pretty sure I haven't broken (but who knows?).
What I mean by "grandchild directory" and what you should expect to see:
moosrc$ make
#... we'll assume this succeeded
moosrc$ mkdir test
moosrc$ cd test
moosrc/test$ tar xvf wherever/you/put/test.tar.gz
moosrc/test$ cd test
moosrc/test/test$
#... edit config and 1/config if you need to
moosrc/test/test$ ./test
Running test #1: ==== PASSED ====
Running test #2: ==== PASSED ====
Running test #3: ==== PASSED ====
Running test #4: ==== PASSED ====
Running test #5: ==== PASSED ====
tl;dr: m5 was an idea I had back when I had a slightly different
theory about how this was all going to work. The details don't matter.
It has its own test suite, which is more about testing m5
than testing moo but it does exercise the server in
not-entirely-boring ways.
If your platform doesn't have some recognizable version
of netcat, ./configure will yell at you and
then you'll have to install one.
Herewith an incantation:
moosrc$ cd ..
$ git clone https://github.com/wrog/m5.git m5
$ cd m5
m5$ autoreconf -i
m5$ ./configure
m5$ make scripts
m5$ export M5MOOEXEC=/path/to/moo
m5$ make check
There are 4 tests; they should all say 'ok'.