Age | Commit message (Collapse) | Author |
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/516bf24
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Both 16x16 and 32x32 variants have been added.
|
|
|
|
There are a few FIXMEs that will need to be addressed, but this
implements most of the prototype method. The FIXMEs are mostly related
to range formatting, which has been entirely ignored so far. But other
than that, the following will need to be addressed:
* Determining flexible day periods must be made locale-aware.
* DST will need to be determined and acted upon.
* Time zones other than UTC and calendars other than Gregorian are
ignored.
* Some of our results differ from other engines as they have some
format patterns we do not. For example, they seem to have a lonely
{dayPeriod} pattern, whereas our closest pattern is
"{hour} {dayPeriod}".
|
|
Unlike the locale, the data locale has Unicode locale extensions removed
(e.g. the data locale for "en-US-u-ca-gregory" is just "en-US"). Cache
the data locale for LibUnicode lookups during formatting.
|
|
|
|
|
|
|
|
|
|
The parsing in parse_calendar_symbols() might be a bit more verbose than
it really needs to be, but it is to ensure the symbols are generated in
a known order that we can control with enumerations.
|
|
This was an oversight in e42d954743056e476bbb1623cfc60e7797a8a6ca.
These fields should always follow the locale preference in the CLDR.
Overriding these fields would permit formats like "h:mm:ss" to result in
strings like "1:2:3" instead of "1:02:03".
|
|
TR-35's Matching Skeleton algorithm dictates how user requests including
fractional second digits should be handled when the CLDR format pattern
does not include that field. When the format pattern contains {second},
but does not contain {fractionalSecondDigits}, generate a second pattern
which appends "{decimal}{fractionalSecondDigits}" to the {second} field.
|
|
Some callers will want different behavior depending on what field is
being provided to the callback.
|
|
TR-35 does define lengths for {ampm}, but they are unused by ECMA-402.
To the contrary, defining the day_period length for this segment will
prevent BasicFormatMatcher from ever selecting a pattern that contains
this segment. Instead, ECMA-402 will only use the short length for
{ampm} segments.
|
|
|
|
|
|
|
|
|
|
Most JavaScript objects don't have private elements, so this reduces the
size of typical JS::Object instances by two pointers.
|
|
Port the ubiquitous dos2unix tool to Serenity. Dos2Unix is a suite of
tools for converting file line endings, from dos/mac to unix and unix
to dos/mac.
|
|
|
|
7530, 7531, 7532, 7533, 7534, 7536, 7684, 81EA, 81EB, 548C,
548B, 4E04, 4E05, 4E09, 4E0A, 4E0B, 4E0C, 7518, 754C, 753D,
753C, 753A, 6743, 4E14, 4E17, 65E5, 65E6, 65E7, 975E, 5211,
5E76, 5E75, 5E77, 5E72, 5E73
https://www.unicode.org/charts/PDF/U4E00.pdf
|
|
4E8C, 4E00
|
|
3220, 3221, 3222
https://www.unicode.org/charts/PDF/U3200.pdf
|
|
3001, 3002, 303E, 303F
https://www.unicode.org/charts/PDF/U3000.pdf
|
|
|
|
If we crashed in the kernel there's no point to sending a signal to the
active process, we're going to panic soon anyway.
|
|
If we're sending an urgent signal (i.e. due to unexpected conditions)
and the Process did not setup any signal handler, we should immediately
terminate the Thread, to ensure the current trap frame is preserved for
the impending core dump.
|
|
This is an encapsulation of the common work done by all of our
single-client IPC servers on startup:
1. Create a Core::LocalSocket, taking over an accepted fd.
2. Create an application-specific ClientConnection object,
wrapping the socket.
It's not a huge change in terms of lines saved, but I do feel that it
improves expressiveness. :^)
|
|
This encapsulates what our multi-client IPC servers typically do on
startup:
1. Create a Core::LocalServer
2. Take over a listening socket file descriptor from SystemServer
3. Set up an accept handler for incoming connections
IPC::MultiServer does all this for you! All you have to do is provide
the relevant client connection type as a template argument.
|
|
This allows us to use TRY() or MUST() when calling it.
|
|
|
|
|
|
It's not safe for this to be a raw pointer, as the child can outlive the
parent.
|
|
It's not safe for this to be a raw pointer, as the imported style sheet
can outlive the rule.
|
|
It's not safe for this to be a raw reference, as CSSImportRule can
outlive the document.
|
|
|
|
These are (mostly) testable now that LibUnicode parses format patterns.
|
|
ECMA-402 doesn't explicitly handle a note in the TR-35 spec related to
expanding field lengths based on user-provided options. Instead, it
assumes the "implementation defined" locale data includes the possible
values.
LibUnicode does not generate every possible combination of field lengths
in its implementation of TR-35's "Missing Skeleton Fields", because the
number of generated patterns would grow out of control. Instead, it's
much simpler to handle this difference at runtime.
|
|
Other implementations unconditionally initialize [[pattern12]] from
[[pattern]] regardless of whether [[pattern]] has an hour pattern of h11
or h12. LibUnicode does not do this. So when InitializeDateTimeFormat
defaults the hour cycle to the locale's preferred hour cycle, if the
best format didn't have an equivalent hour pattern, [[pattern12]] will
be empty.
|
|
TR-35 describes how to combine date, time, and available formats with
date-time format patterns to generate more available format patterns:
https://unicode.org/reports/tr35/tr35-dates.html#Missing_Skeleton_Fields
Use these steps to generate ~400 new patterns for each calendar. These
are required for ECMA-402's BasicFormatMatcher to produce reasonable
results.
|