[DGD] Kotaka v0.50
Raymond Jennings
shentino at gmail.com
Thu Jun 28 09:31:07 CEST 2018
Finally got to a new release of kotaka.
This is mostly internal cleanups.
New policy on constructors, destructors, and patchers:
They are useful as courtesies, but the ability for an object to
rewrite its inheritance tree at will eliminates a few guarantees, so
as a middle of the road approach I thought it wiser to make those
caveats part of the policy and officially put inheritables on notice.
Full notes are in the top level documentation.
A new patcher interface has been written.
See git commit log for full information.
Raymond Jennings (98):
Lock down the full rebuilder to appropriately privileged code
Detail the deprecation process for constructors and destructors
Add our (well, my) internal docs for how to handle upgrading Kotaka
Add a bit to the readme, also do a minor bit of reformatting
Add header for INSTALL file (workaround for git freaking out
about conflict marker)
Small simplification in ObjectD
Add final version of safe_upgrade_versions
Update InitD for compartmented upgrades
Final incarnation of upgraded
fixup initd
Add upgrade policy on the dev side
Force System SubD to recompile on a System module upgrade
We will eventually stop autoregistering modules. In the future,
modules can only be booted and shut down via ModuleD
Formal roadmap style documentation regarding pending API changes
ObjectD needs recompiled on next upgrade
Issue a diagnostic if a module is shut down due to a missing
initd file during upgrade
Have ModuleD recompiled on upgrade
Inform admin when System module is upgraded
Have system upgrade initiate module upgrades
Give Test module enough ticks to complete its tests
Do tests in parallel via callouts
Add new API for single archetype as documented in UPGRADES for
version 0.50
Finish deprecation of multiple archetype setting per version
0.50 preparation
Flag initds who attempt to return constructor or destructor
information, now that it is deprecated
Fix typos in multiple archetype deprecation
Stop using constructors and destructors with things
Convert mandatory destructor in thing library to a cooperative
one that inheriting objects should call manually as needed
Pass destruct call from Game thing library to thing library
When a Game thing destructs, pass the call up the chain to the libraries
Remove obsolete call to destruct the saveload object, upgrade
was in version 0.49
Rename creator function for thing library
Update a copyright date
Move upgrade recompilations to the upgrade_module lfun
Increase Intermud's tick limit to 5M
When shutting down the Ecru module, don't try to destruct kernel objects!
When resetting a module's resource limits after shutting it down
just loop through every resource
For now, be gentle with a module shutdown. Only stop it from
creating more objects.
Fix typo in module resource thaw fix
Add help command to objconf
Update developer document for managing user-side upgrades
Reorder misleading messages in saveworld and loadworld verbs.
We shouldn't say "done" for an asynchronous process, there could be
errors or reboots
When doing a System upgrade, have the System module upgrade
itself before upgrading the other modules. It's special, treat it as
such
Add master TODO file
Make a note that (maybe in the future) a module can be nuked
even when it's shut down
Have System module's StatusD provide a diagnostic if it gets
queried for a banner for a sitebanned IP
Mass is in kilograms, not cubic meters...
We're going to have to rearrange the api change schedule
We shouldn't stop an initd from being destroyed, there may be a
good reason, and a module should always be allowed to mess with itself
if it wants to
Don't bury old logs when they get too big, just delete them
State directory for snapshots is now explicit and not a symlink
Ecru doesn't depend on Game
Boot Game after system is loaded
String depends on Ecru
We will make these changes when we get to them
Fix a small typo
Make sure a siteban check doesn't fail to disable a banned
connection if the responsible connection manager burns all its ticks
Add hook function and documentation to UserD library
Archetype api change no longer version tied
Take note of the DoS opportunity of getting a backlog of log
spam that jams the logd when dgd decides to garbage collect
Make note that destructors are being deprecated, and that the
bottom program should call up the chain as needed. Also, inherits are
at the mercy of inheritors for preservation of data.
Turns out, patchers are also at the mercy of inheritors
Stronger deprecation of constructors, destructors, and patchers
PatchD needs to be removed soon
Fix sloppy typing in UPGRADE
Make note of new patching api we will use
More information and cleanup on the pending api changes
Objects can ask to be patched if they want to
Move API change list to separate file
Amendment of patching interface
Document how a system upgrade should happen. System is special.
Undeprecation of constructors and destructors but caveats have been added
As before, we'll do a transition
Update commentary on upgrades and patching
Organize system libraries
Add multilevel sparse array structure
Fix bad stubbing of moved list library
Various fixes in maparr
New patching api
Fix a small typo in UPGRADE-API
Add test for multilevelmaparr
Make notes of old code in ObjectD and PatchD that needs cleaned out
We need more callouts for now to handle the load of upgrade calls
Set stack limit for System module to 50
Streamline INITD's upgrade process a bit.
As a temporary test, return a patcher for the touch autolib
touch autolib updates
Mark previous patching process as obsolete
Use new patching process in ObjectD, also handle upgrade calls differently
Allow return value for touched objects to be passed back to dgd
via ObjectD
Add a safety test for ObjectD for when we later remove the old
upgrade queue
Add a creator for PatchD
Nix some dead code
Don't nuke the old patch bigstruct if we never added anything to it
Add new patching process to PatchD
Remove System UpgradeD
Have rebase script abort if there's a conflict
INITD:
Version 0.50
More information about the DGD
mailing list