ChainPlacer.js creates a new array that it fills with the -1 value before computing its clumps. This is slow.
By simply storing values differently, we can avoid doing that altogether, leading to faster mapgen.
Hard to say in general but I think this might be about 3-4% faster on a typical map.
The migration to git broke the translation of language names in the
credits, as the translators.json, necessary for extracting the language
strings wasn't present anymore when running update_templates.py. This
commit should fix this.
- Shallow-freezing of objects is never used in our codebase, so remove
that code path.
- Deep-freeze is bugged in recent versions of SpiderMonkey (see bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1930258). Until a fix
and/or a better API is provided, reimplement this feature by
recusively freezing object properties.
- Add tests for the deepfreeze function.
The shell option "set -e" has a tricky, but standard, behaviour:
Anything called on the left side of a || or && token ignores "set -e",
so failure in a command in a subshell called on the left side of "|| die"
does not prevent the execution of the following commands in the subshell.
Adding explicit "|| die" calls after each command that could fail (and
should interrupt the process) works around this behaviour, by emulating
the intuitive "set -e" behaviour.
Unless minimal cflags is set add -Og or equivalent to CXXFLAGS for debug
build configuration.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
FORTIFY_SOURCE relies on optimizations being enabled which is only the
case for the release configuration. Therefore remove it from the debug
configuration as to prevent the compiler issuing a warning on each
invocation.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
DEBUG is unused by pyrogenesis and unconditionally adding it to defines
prevents building against a non debug version of spidermonkey. This will
allow building only one copy of spidermonkey, which can be trivially be
replaced with the other depending on needs independent of pyrogenesis
debug or release build.
This also allows to build either build configuration against system
spidermonkey, which obviously is either one build type or the other.
Requires a compilecheck until the pc file gets fixed upstream.
A comment in the spidermonkey build.sh says on FreeBSD spidermonkey
debug configuration doesn't even build and so pyrogenesis debug build
wasn't possible either.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
During the removal of glooxwrapper the function GetJID was mapped to
getID. This results in NetClient querying for host jid not getting the
right value which prevents hosting a game in the lobby.
Reported-by: Dunedan
Refs: #7203
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This uses ./build/workspaces/default as location for generated build
files as well as build products. Using the name "default" to avoid the
dilemma gcc vs clang vs premake generator. Doesn't impact scripts
already using --outpath and allows running premake5 --help without a
wrapper.
Also update .gitignore to make using arbitrary workspaces cleaner.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This option doesn't handle includes, further we rely on system includes
and pkg-config to locate dependencies.
For systems where installing into local is reasonable this paths should
already be in system/ld paths. So in practice this offers no value.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This option is needed to be able to use more than 2GB on 32bit Windows
builds.
Having to explicitly enable this turns out to be a pitfall. Release
builds are done with this option enabled and when then building from
source and running out of memory it's not immediately obvious what the
reason is.
The documented intent is that this behaviour might be useful to find
memory leaks. The large-address-aware enabled build already perfectly
serves this role this days and the memory pressure is an important
reason for the ongoing Windows 64bit build efforts. Also there are
arguably better tools for this purpose.
Refs: commit a8403bd7e5
Refs: issue #1619
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This wrapper was meant to support multiple C++ ABIs with a single
pre-built gloox library wrap as a C library. A new ABI change was
rejected a few years back, so this will probably take a while for it to
be on the table again. With the bug tracker and mailing list currently
unavailable and known TLS issues we might have replaced gloox by then
anyway.
Supporting multiple ABIs with the current setup isn't an issue either
and is already done for 32bit vs 64bit ABI on Windows.
Therefore use gloox types directly in lobby code instead of wrapper
types and delete the wrapper and build-integration.
Migrate to override where applicable, as it helped avoid subtle
differences in signatures and finding missing inheritance of LogHandler.
Finally use version check instead of os check to work around Windows
using the 1.1 development branch instead of releases.
Fixes: #7198
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Itms