As with other special cases, this depends on the property name.
The UIDimension code is kept separate since it can handle both integers
and strings, and the string names for special dimensions don't match
with the enum names.
There's the "font_type" property which currently only handles
fixed-width yes/no, so until we get a proper font type enum and
associated enum property, this is better to use from GML instead of a
special case in the GML compiler.
This encoder can handle all integer formats and sample rates, though
only two channels well. It uses fixed LPC and performs a
close-to-optimal parameter search on the LPC order and residual Rice
parameter, leading to decent compression already.
This interface is very simple for the time being and can be used to
provide encoding functionality in a generalized way. Initialization and
parameter setting are intentionally not abstracted for now, since this
is usually very format-specific. We just need a general interface for
writing samples and errorable finalization.
Just like with input buffered streams, we don't currently have a use
case for output buffered streams which aren't seekable, since the main
application are files.
This allows to compare CSSPixels with AvailableSize without converting
it to CSSPixels, which might leak saturated (infinite) values into
layout calculations.
To ensure this happens without duplicating code, we allow forcing a
StringBuilder object to only use the inline buffer, so the code in the
AK/Format.cpp file doesn't need to deal with different underlying
storage types (expandable or inline-fixed) at all.
The following changes take effect:
1. Annotate FixedStringBuffer => `FixedStringBuffer` in many places.
2. Remove non-existing helpers for FixedStringBuffers. I added them
previously but even then they were removed in a following fixup so these
references were never valid. Therefore let's just put a vague reference
to the fact that we have some helpers for this class in the Kernel, and
let people to figure out quickly by themselves for this topic.
3. Put a sentence to explain that FixedStringBuffer objects are not only
being used in syscall handling code, but also for storing actual data in
both the Thread and Process classes as well.
More error propagation is still needed, we really want the parser to
just crash early when it encounters unexpected input, instead of trying
to carry on like nothing happened.
I think ErrorOr<unsigned> is *much* better than returning (unsigned)-1
to indicate an error ;)
We're now sniffing the incoming data to verify the server has sent a
full response, instead of passing partial data to our IMAP parser.
Our parser really can't handle partial input very well, so for the time
being, this heuristic does a much better job of verifying we have full
response before parsing.
It doesn't yet handle unprompted untagged reponses, nor the
"continuation request" responses that start with a `+`, but we don't
fully support those yet.
I couldn't run the parser in a debugger like I normally would, so I
added printouts to understand where the parser is failing.
More could be added, but these are enough to get a good idea of what
the parser is doing. It's very spammy, though, so enable it by flicking
the IMAP_PARSER_DEBUG switch :^)
This lets us bubble up errors from `LibIMAP::Client::send_command()`,
which can happen if the connection hangs or is taking a long time, and
the user closes Mail.
During testing, I found that some Email clients/providers format the
From header field content with a lower case f, so `from:` instead of
`From:`. Our client previously gave up if it couldn't find one that
starts with a capital F. Now, we try both, and provide a fallback if
neither were found.
`MailWidget::m_imap_client` is only assigned after a connection is
established, so the user might close the main window before that
happens, especially if the connection hangs for whatever reason.
Now we check the `OwnPtr` before working with it.
While LLD and mold support RELR "packed" relocations on all
architectures, the BFD linker currently only implements them on x86-64
and POWER.
This fixes two issues:
- The Kernel had it enabled even for AArch64 + GCC, which led to the
following being printed: `warning: -z pack-relative-relocs ignored`.
- The userland always had it disabled, even in the supported AArch64 +
Clang/mold scenarios.
