Some locales in the CLDR have alternate default numbering systems listed
under "defaultNumberingSystem-alt-*", e.g.:
"defaultNumberingSystem": "arab",
"defaultNumberingSystem-alt-latn": "latn",
"otherNumberingSystems": {
"native": "arab"
},
We were previously only parsing "defaultNumberingSystem" and
"otherNumberingSystems". This odd format appears to be an artifact of
converting from XML.
This isn't particularly important because this generates code that is
quite hidden from outside callers. But when viewing the generated code,
it's a bit nicer to read e.g. enum identifiers such as "MinusSign"
rather than "Minussign".
As soon as we enable the first PS/2 port on the I8042 controller, the
output buffer may become full. We need to drain it before attempting
any new commands with the controller (such as enabling the second PS/2
port).
Fixes#10872.
Apparently, qemu-system-* changed its name.
On Debian/Ubuntu, genext2fs does not make a difference: The only user of
this command, Meta/build-image-qemu.sh, runs as root anyway, and tries
to do 'mount _disk_image mnt/' first. Debian/Ubuntu always have drivers
for ext2 available, so this command has no good reason to fail, and
trying to use genext2fs might only obscure any problems that mount
encountered.
Finally, Debian Bullseye (released 2021-08-14) contains gcc-10, so the
instructions on how to upgrade are now obsolete.
Before this patch, both Bitmap and ImageDecoder had logic for guessing
which image codec to use for a chunk of data. Bitmap now defers to
ImageDecoder so that we only have to do this in one place.
There's room for improvement in the ImageDecoder heuristic, but that's
outside the scope of this change.
We had a bunch of old unused wrapper functions for each image codec that
would load a supported image with a given path. Nobody actually used
them, so let's just get rid of load_png(), load_gif(), etc.
We were passing raw Gfx::Bitmap objects into the various image decoders
instead of encoded image data. This made all of them fail, but the test
expectations were set up in a way that aligned with this outcome.
With this patch, we now test the codecs for real. Except ICO, since we
don't have an ICO file handy. That's a FIXME.
In particular, we track separately whether each AtExitEntry has already
been called, through a separate Bitmap. This has several side-effects:
- We now call malloc() during __cxa_finalize(). I believe this is fine,
and at that point during program execution memory pressure should be
low anyway.
- An attacker could prevent arbitrary entries from executing by writing
to atexit_called_entries. However, this already was possible (by
setting atexit_entry_count to zero), and this path is even more
troublesome (the attacker needs to overwrite atexit_called_entries,
and a region serving as *atexit_called_entries.m_data, and magically
know exactly how many entries already exist.)
- This reduces the size of AtExitEntry from 16 to 12 (on i686). As such,
we can reduce the initial memory allocation from two to one page,
reducing the initial capacity from 512 to 341 entries (or 256 to 170,
on x86_64). It seems that most programs only use 36-47 entries anyway.
For 'true', this shaves off about 69 syscalls, as measured by strace.
Previously, a collection of notes (Vector or Array) would be created and
promptly deleted for every sample (at least 44 thousand times per
second!). This was measured to be one of the most significant
performance drawbacks as well as the most obvious performance
improvement I could currently find here. Although it will not cause
Piano to lag currently (at least on virtualized systems), I see an
incoming issue once we get the capability to use more processors.
Now, we use a HashMap correlating pitches to notes, and Track reuses the
data structure in order to avoid reallocations. That is the reason for
introducing the fast clear_with_capacity to HashMap.
Always throws at the moment, because parse_temporal_month_day_string()
is basically a stub, and parse_iso_date_time() isn't functional either.
The spec issue has been resolved though, so I figured we might as well
get one small step further :^)
Same as Vector, ByteBuffer now also signals allocation failure by
returning an ENOMEM Error instead of a bool, allowing us to use the
TRY() and MUST() patterns.
Instead of signalling allocation failure with a bool return value
(false), we now use ErrorOr<void> and return ENOMEM as appropriate.
This allows us to use TRY() and MUST() with Vector. :^)
First off, this verifies that an initial value is always provided in
Properties.json for each property.
Second, it verifies that parsing that initial value succeeds.
This means that a call to `property_initial_value()` will always return
a valid StyleValue. :^)
