And use it to _correctly_ implement state saving for generators.
Prior to this, we were capturing the caller frame, which is completely
irrelevant to the generator frame.
There is quite a lot to be done here so this is just a first pass at
number formatting. Decimal and percent formatting are mostly working,
but only for standard and compact notation (engineering and scientific
notation are not implemented here). Currency formatting is parsed, but
there is more work to be done to handle e.g. using symbols instead of
currency codes ("$" instead of "USD"), and putting spaces around the
currency symbol ("USD 2.00" instead of "USD2.00").
It was previously holding a StringView, which was either a view into a
LibUnicode-generated string or a string passed from the user.
Intl.NumberFormat will need this record to hold internally-created
strings, so a StringView will not suffice (the way the steps are laid
out, that view will ultimately end up dangling).
This shouldn't be too wasteful since the StringView it was holding was
converted to a String eventually anyways.
This will be needed for the ComputeExponentForMagnitude AO for compact
formatting, namely step 5b:
Let exponent be an implementation- and locale-dependent (ILD) integer
by which to scale a number of the given magnitude in compact notation
for the current locale.
A number formatting pattern in the CLDR contains one or two entries,
delimited by a semi-colon. Previously, LibUnicode was just storing the
entire pattern as one string. This changes the generator to split the
pattern on that delimiter and generate the 3 unique patterns expected by
ECMA-402.
The rules for generating the 3 patterns are as follows:
* If the pattern contains 1 entry, it is the zero pattern. The positive
pattern is the zero pattern prepended with {plusSign}. The negative
pattern is the zero pattern prepended with {minusSign}.
* If the pattern contains 2 entries, the first is the zero pattern, and
the second is the negative pattern. The positive pattern is the zero
pattern prepended with {plusSign}.
The number system data in the CLDR contains information on how to format
numbers in a locale-dependent manner. Start parsing this data, beginning
with numeric symbol strings. For example the symbol NaN maps to "NaN" in
the en-US locale, and "非數值" in the zh-Hant locale.
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.
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 :^)
