It's not the `to_uint<u8>()` call that would fail, if we have a value
for these productions they will always be valid numbers. We do need to
provide a fallback for when that's not the case and any of them is
undefined, i.e. an empty Optional.
This is the start of a parser for the ISO 8601 grammar used in the
Temporal spec:
https://tc39.es/proposal-temporal/#sec-temporal-iso8601grammar
We will, on purpose, not use a generic ISO 8601 parser from AK or
similar for two reasons:
- Many AOs make specific assumptions about which productions exist and
access them directly, even when they're part of a larger production.
- The spec says "The grammar deviates from the standard given in ISO
8601 in the following ways:" and then lists 17 of such deviations.
Making that work with a general purpose parser is not worth it.
The public API is not being used anywhere yet, but will be in the next
couple of commits. Likewise, the Production enum will be populated with
all the productions accessed directly (e.g. TemporalDateString).
Many thanks to Ali for showing me how to improve my initial approach
full of macros with a nice RAII helper - it's much nicer :^)
Co-Authored-By: Ali Mohammad Pur <mpfard@serenityos.org>
We now decrement the return address of the previous frame by one to get
the address of the call instruction and use this address in the
backtrace.
This results in more accurate source position information than what we
previously had when using the return address.
Previously, when the --unlink flag was passed to CrashReporter, it
unlinked the coredump file immediately after reading it.
This change makes it so the coredump file is deleted when CrashReporter
exits.
ProcessInspector is an abstract base class for an object that can
inspect the address space of a process.
Concrete sub classes need to implement methods for peeking & poking
memory and walking the loaded libraries.
It is currently only implemented by DebugSession.
The goal of these more recent additions to the Dockerfile is to provide
a working copy of SerenityOS with the toolchain prebuilt. To me, these
additions feel misplaced:
- The toolchain is built assuming the i686 architecture, which may not
be what you want.
- You get a shallow clone of the project limiting you in your abilities
to navigate through the project's history or bisect.
- There's this awkward directory structure of `/serenity/serenity-git`
and `/serenity/out`.
The Dockerfile is immensely useful for building SerenityOS in a
containerized environment, separate from the host's environment. If we
want to automate builds, we can always use CI or extend this image to
do so. For now, let's remove the `git clone` and associated actions.
Fixes#9310.
Right now, this is a bit of a hack. We can't set a keymap to only apply
to the test area, so we set the system keymap instead, while also
keeping track of the "real" current keymap. Whenever the settings are
applied, we update what that "real" keymap is, and when we exit, we
revert to that keymap.
Basically, it behaves as you would expect, apart from it also affecting
other applications you are typing in while the KeyboardSettings window
is open with a different keymap selected.
This is functionally the same as before, as selecting a tab fires Show
and HideEvents. But this way, we don't need to directly access the
TabWidget, which will make using SettingsWindow simpler.
The FooSettings apps have quite a lot of boilerplate just around
creating a tabbed window with the same styling and the same row of
buttons along the bottom. So, let's extract that out into a class we can
reuse! :^)
You create a SettingsWindow instead of a regular Window, passing a title
and a flag to determine if a "Defaults" button is shown. Then call
add_tab() to add tabs to it. Tabs are widgets extending
SettingsWindow::Tab, which has methods for saving and resetting the
values.
For an empty glyph (all pixels initially clear), this makes no
difference. However, if the glyph for the selected code point already
contains some set pixels, pasting used to "add" the set pixels, instead
of overwriting.
An image document is the synthetic DOM::Document we create to wrap an
image when you open the URL of an image directly in a web view.
The path that creates these documents will now also call out to the
separate ImageDecoder process for the actual decoding work.
This saves user code from having to parse the numbers, as we already did
that while Tokenizing. :^)
As a bonus, we now round extremely large integers to the closest
available value, like the spec tells us to.
Previously if a commit message contained any carriage returns it would
correctly fail the 'contains CRLF line breaks' test, but it would also
report 'Commit message lines are too long' and 'Commit title ends in a
period', even if neither is true.
