[DGD] Kotaka 0.59

[Raymond Jennings]

A new release of kotaka.

git://github.com/shentino/kotaka.git v0.59

Some major points to mention:

# A new upgrade system

Ok, so I totally tried to do a comprehensive upgrade system but that didn't
work as planned.  I realized that mandatory constructors and destructors
were completely USELESS on account of the fact that downstream objects on
the inheritance tree could arbitrarily inherit or disinherit a library at
will during their own compilation.

So instead I have the following regime:

* When an object is compiled, ObjectD will query the associated initd for
its constructor, destructor, and patcher.  This implies that you should
always make sure that the initd itself is up to date at the time, which
includes any recompiles to update from amended source code if needed.

* When an object is cloned (or compiled, if not inheritable), its
constructors are called.  The object's constructors are every registered
constructor for itself, as well as its inherits, which were gathered
earlier when the inheritables were themselves compiled.  Constructors are
called in order such that the constructors for all of a program's inherits
are called before the constructor for the program itself, which leaves the
constructor for the object itself the last to be called, and before the
create() function.

* On destruction, the destructors are called in like manner to
constructors, just in the reverse order and after the destruct() call.
This is where one of the caveats comes in: If an object is recompiled such
as to remove an inheritable from its tree, the associated destructor will
NOT be called when the object is destructed.  I realized that there wasn't
really a good way to stop this that I could think of.  I might later
consider using an atomic compile to catch disinheritance of destructors.

* When an object is recompiled (only possible btw for non inheritables), it
is flagged for patching.  PatchD will call_touch it and all of its clones
such that the next time the object is touched its patchers will be called.
The patchers are as with constructors the patchers registered by the object
and all of its inherits.  Furthermore, a batch job is started that will
eventually touch the object and all of its clones.  Another caveat: the
user recompiling a patchable object is free to interrupt a patch job by
again recompiling the object before it finishes, which will cause it to be
aborted and restarted from scratch.

# Test suite

I reorganized the test suite provided by the Test module.  All tests now
run in the background via chains of callouts.  Furthermore, any failed test
will get the mud shut down with the new abort mechanism I provided in
System.

Addition of further test suites is anticipated to cover each module.

# Module management

This has been implied for awhile, but it is now time to make the
terminology explicit.

Each directory under /home (except for Secret), as well as everything
outside of a /home directory, is considered to be part of a module.

For objects under a directory in /home, they are part of the module named
after that directory.  Anything outside is part of the nil module.

In the past, a module was implied to be online if the corresponding initd
was compiled.  Now, this status will be tracked explicitly by ModuleD, and
the initial status recorded by ModuleD for a warm update will be the
current existence of the initd grandfathered in as the online status.

A module is either online (1), offline (0/nil), or in shutdown (-1).  A
module in shutdown state was forcibly shut down by ModuleD, is currently
banned from cloning objects or issuing callouts, and a background task in
ModuleD is currently destructing all objects owned by that module, and may
optionally have a flag for the module to be rebooted once cleanup is
completed.

The ONLY way for a module to be officially booted is to call boot_module in
ModuleD specifying the name of the module to boot.

For the purposes of module management, a module is online from the
perspective of ModuleD the moment its initd is compiled and its create
call, as well as any constructors, are called.  The module will only be
marked as online if the initd is successfully compiled and its constructors
and create function succeed.  Any errors will cause the module boot to be
aborted and the module will be left marked as offline, with any already
compiled or cloned objects left as is.

Modules MUST be prepared to be forcibly shut down at any time, and SHOULD
be prepared for any of their dependent modules to be shut down at any
time.  Module dependencies are not enforced at module boot time and from
ModuleD's perspective are completely independent from one another.  Any
dependency enforcement is the responsibility of the modules.

A module in an online state SHOULD remain able to operate on a sane basis
without errors regardless of the status of any other modules, but MAY
refuse to provide service if one of its dependencies is not satisfied.  It
is suggested that any module requiring another module boots that module in
its initd's create function.

It is forbidden to inherit from a library if the library's corresponding
initd is not loaded.



Miscellaneous changes:

Various simplifications
Self contained destruct and compile of libs in INITD
Help command was reformatted
Remove some atomic qualifiers that weren't needed
Simplify object overflow prevention
Simplify ErrorD by using standard logging mechanisms to post
IDD instead of CatalogD
Rewrite ErrorD
Remove Bigstruct test
Increased sanity checking for System code
Ban lists are now grouped in 5s on display
Allow nested sprints to skip checks for duplicate structures, to avoid
array overflow
Readd staggered dumping in DumpD
Embed verb help in verb sources
Rat out if i3 sends us control char spam
I3 module more robust
with passwords
Handle pinkfish
Migrate documentation to markdown
Background the test suite
Abort on a test suite failure
Break up world saves into directories