Remove useless tinythread import in PlugLoad-windows.cpp
Remove seemingly useless tinythread import in LuaTools.cpp
Factor out tinythread in LuaApi.cpp
Removed unused tinythread in LuaWrapper.cpp
Removed unused tinythread include in LuaTypes.cpp
Removed unused tinythread include in ColorText.cpp
Factor out tinythread in Console.h
Factor out tinythread in Console-posix.cpp
Factor out tinythread in Console-windows.cpp
Factor out tinythread in renderer_light
Factor out tinythread in DataDefs.cpp
Remove unused tinythread include in RemoteClient.cpp
Add includes for new mutex and conditional_variable usages in PluginManager
Factor out tinythread from devel/memview, renderermax/renderer_light, and rendermax/renderer_opengl plugins
Remove usages of tinythread in various CMakeLists.txt files, in .ycm_extra_conf.py, and delete tinythread itself
Delete tinythread from LISCENSE.rst
excise tinythread: fix deadlock in pluginmanager
excise tinythread: remove improper header
excise tinythread: fix double unlock. fix plugin typo
Without being declared with `extern "C"`, `plugin_globals` is mangled, with a
`cxx11` suffix.
We can't add `extern "C"` to the `DFhackDataExport` macro because GCC does not
allow initializing any `extern` variables inline, including `extern "C"`.
refactor is a straight copy-paste. this code could really stand some
cleanup (unused vars, unnecessary use of the MapCache layer, forced
allocation of all blocks even if they are not being unhidden, etc.), but
that can come in a later PR.
Alter World to use Persistence instead of storing data in historical figures.
Fake historical figures will be converted to the new format when a world is loaded.
Added plugin_save and plugin_load functions to the plugin API.
Made the weird int7/int28 code that was in the old persistence API slightly safer.
* load/unload/reload are no longer restricted to plugins that exist
on startup
* Names passed to DFHACK_PLUGIN must match the plugin's filename
(remotefortressreader vs RemoteFortressReader, counters vs probe)
* "plug" output lists all plugins and state/command information
* Deleted plugins can be reloaded again if they are replaced
* load/unload/reload don't fail silently with broken plugins
* Built-in commands are recognized internally (e.g. "help help"
does not display "help is not a recognized command"), although help
for them is not yet implemented
* New command: "type" (bash-like) - shows where/how a command is
implemented
* "plug" can accept multiple plugin names
* "ls" displays more information about unloaded/unrecognized plugins
* "load all" changed to "load -all" (or "load --all", "load -a", ...)
git is run every time 'make' is run, but the generated include file
is only updated when necessary. Plugins will be loaded successfully
if their DFHack version matches core's (assuming OpenLibrary()
succeeds), but will produce a warning if their git commit doesn't
match core's.
This allows completely avoiding the call overhead if there
are none. The downside is that the event object now has to
be a userdata with lots of metamethods.
- This context requires core suspend lock and asserts it in a few places.
- Special 'event' objects are introduced. They can be invoked as
functions, in which case they iterate all their fields and call
them as functions. Errors are printed and consumed.
- When a plugin is opened by the core context, events registered in
a special array are linked to it. The system is organized so as to
avoid even trying to pass the event to lua if the module isn't loaded.
- To ensure reload safety functions have to be wrapped. Every call
checks the loaded state and locks a mutex in Plugin. If the plugin
is unloaded, calling its functions throws a lua error. Therefore,
plugins may not create closures or export yieldable functions.
- The set of function argument and return types supported by
LuaWrapper is severely limited when compared to being compiled
inside the main library.
Currently supported types: numbers, bool, std::string, df::foo,
df::foo*, std::vector<bool>, std::vector<df::foo*>.
- To facilitate postponing initialization until after all plugins
have been loaded, the core sends a SC_CORE_INITIALIZED event.
- As an example, the burrows plugin now exports its functions.
This is an incompatible change to the plugin ABI.
The Console is not thread-safe unless used indirectly
via color_ostream_proxy, so everything should use their
per-thread stream.
Paxton Schweigert
lethosor
Myk Taylor
Josh Cooper
Ben Lubar
Pauli
jj
Alexander Gavrilov
expwnent
Petr Mrázek
jj