mirror of
https://github.com/fluffos/fluffos
synced 2026-08-12 18:26:06 -04:00
ea57b78923
src/packages/dwlib had no CMakeLists.txt, so it silently never built (for roughly a decade). Add the standard package wiring behind a new PACKAGE_DWLIB option (default OFF, matching its status as a Discworld-specific optional package) and fix the one API bit-rot spot (find_in_mapping now takes the key by value). Enabling it exposed a build-system gap: packages.fullspec (the make_func input) did not depend on the generated enabled-package list, so toggling any package option left a stale efun table -- predefines said the package existed while its efuns didn't. packages.fullspec now depends on packages.autogen.h. Also corrects the replace_dollars() test to the efun's real marker/replacement-pairs API. Verified: full LPC testsuite passes both with -DPACKAGE_DWLIB=ON (dwlib efun tests active) and with the default OFF configuration. Also corrects the clean_up() apply documentation (EN + zh-CN): the argument is the program's reference count (0 for clones), which the apply cache can inflate -- not a strict inherited flag (issue #179). Fixes #467 Fixes #179 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016FMBJLkpkpVpZdz6PWzeWe
1.2 KiB
1.2 KiB
| title |
|---|
| object / clean_up |
clean_up
NAME
clean_up - periodically called in inactive objects
SYNOPSIS
int clean_up( int inherited );
DESCRIPTION
The clean_up() function is called by the driver on a regular basis in
all objects that have been inactive for the time specified for
clean_up() in the runtime configuration file.
The argument is 0 for clones. For blueprints it is the program's
current reference count: 1 for a plain loaded object nothing else
uses, and greater when clones of it exist, other programs inherit it,
or the driver's function-call cache still holds a reference to it.
Treat values above 1 as a hint that the program is (or was recently)
in use, not as an exact inheritance count, and avoid destructing in
that case.
If clean_up() returns 0, clean_up() will never be called again on that
object unless the object asks for it again with request_clean_up().
If it returns 1, it will be called again when the object remains
inactive for the specified clean_up() delay.
One thing that might be commonly done by an object in this function is
destructing itself to conserve memory.
SEE ALSO
request_clean_up(3)