Ensures that a fixed-point value is always initialized
This likely also fixes several cases of uninitialized values being
operated on, since we have multiple areas in the codebase where the
default constructor is being used like:
Common::FixedPoint<50, 14> current_sample{};
and is then followed up with an arithmetic operation like += or
something else, which operates directly on FixedPoint's internal data
member, which would previously be uninitialized.
This calls round_up(), which is a non-const member function, so if a
fixed-point instantiation ever calls to_uint(), it'll result in a
compiler error.
This allows the member function to work.
While we're at it, we can actually mark to_long_floor() as const, since
it's not modifying any member state.
I did some tests on my own fork, and we're writing to ~/.transifexrc but
the client can't seem to read that file. maybe issue with $HOME or
something.
Workaround is to set TX_TOKEN environment variable and now the pesky
~/.transifexrc file is not needed.
The function prototype appears to care whether we are loading capture
devices or not, and SDL_GetAudioDeviceName has a parameter to use it,
but for some reason it isn't.
This puts `capture` where it goes.
Currently we're using the python client which uses an API that they
state will sunset Nov 30, 2022.
`tx push -s` actually appears to work properly, some of the other
commands require tweaking, like instead of suggesting `tx pull -a` in
dist/languages we need to suggest `tx pull -t -a`
Right now this looks like a distro specific problem, but we'll have to see.
Over on Gentoo: with lz4 1.9.3 there is a lz4::lz4 library target, with 1.9.4 it's no longer
mentioned in the cmake files provided by the package. (/usr/lib64/cmake/lz4)
arch and openSUSE have lz4 1.9.4 available so I checked there,
they only have .pc files for pkg-config, so asking for "lz4::lz4" works as usual
MSVC does require "lz4::lz4" to be asked for
bunnei