The main point is to bring this in line with all the other file copying,
which is always done via rsync.
On my machine this leads to very little speedup, but I'm also on WSL, so
🤷
Timings:
Before:
Time (abs ≡): 20.440 s [User: 133.928 s, System: 12.290 s]
After:
Time (abs ≡): 20.346 s [User: 135.534 s, System: 11.207 s]
pandoc is a single-threaded and pretty slow application, so we can run
it in the background and "synchronize" before generating section
indices.
Timing results:
Before:
Time (abs ≡): 59.833 s [User: 49.541 s, System: 6.943 s]
After:
Time (abs ≡): 20.440 s [User: 133.928 s, System: 12.290 s]
(both generated with hyperfine -p "rm -r output || true" -r 1
Meta/build-manpages-website.sh )
For now, we create simple but complete indices and actually generate the
HTML for the manpages in subsections. For these purposes, switch to
using "find" as a file finding tool everywhere, instead of the very
limited globs from before.
For example, in Solitaire, when dragging a card around, it's common for
other implementations to highlight the card underneath the dragged card
if that other card is a valid drop target. This implementation will draw
a rounded rectangle within the edges of the highlighted card, using a
rudimentary complementary color of the board background color.
The biggest difference is that -m32 is no longer important, and in fact
breaks every 64-bit setup.
Also, defining ENABLE_UNICODE_DATA, ENABLE_COMPILETIME_FORMAT_CHECK, and
__SSE__ makes some code "visible" in the #ifdef sense, which improves
syntax highlighting.
This adds the option to pass a subpixel offset when fetching a glyph
from a font, this offset is currently snapped to thirds of a pixel
(i.e. 0, 0.33, 0.66). This is then used when rasterizing the glyph,
which is then cached like usual.
Note that when using subpixel offsets you're trading a bit of space
for accuracy. With the current third of a pixel offsets you can end
up with up to 9 bitmaps per glyph.
A virtual method named device_name() was added to
Kernel::PCI to support logging the PCI::Device name
and address using dmesgln_pci. Previously, PCI::Device
did not store the device name.
All devices inheriting from PCI::Device now use dmesgln_pci where
they previously used dmesgln.
Previously the stats was only updated once the first callback from
refresh_timer fired.
It now makes an early stats update on launch, so something will appear
in the graphs.
This was a footgun waiting to happen. The StringView encoder is only
used internally within IPC::Encoder to encode DeprecatedString. It does
not encode its null state nor its length. If someone were to innocently
use the StringView encoder as it is, and then decode a DeprecatedString
on the remote end, the decoding would be corrupt.
This changes the StringView encoder to do the work the DeprecatedString
encoder is currently doing, and the latter now just forwards to it.
While refactoring the IPC encoders and decoders for fallibility, the
inconsistency in which we transfer container sizes was a frequent thing
to trip over. We currently transfer sizes as any of i32, u32, and u64.
This adds a helper to transfer sizes in one consistent way.
Two special cases here are DeprecatedString and Vector, whose encoding
is depended upon by netdb, so that is also updated here.
- Return StringView instead of DeprecatedString from function
returning only literals
- Remove redundant cast
- Remove "inline" -- the function is defined in a cpp file,
so there's no need for the linkage implications of `inline`.
And compilers know to inline static functions with a single
use without it. (Normally I'd remove the `static` instead,
but this is in an `extern "C"` block, and it doesn't matter
enough to end that block before the helper function and
reopen it enough after)
`inline` already assigns vague linkage, so there's no need to
also assign per-TU linkage. Allows the linker to dedup these
functions across TUs (and is almost always just the Right Thing
to do in C++ -- this ain't C).
Before this patch, the generation of the encryption key was not working
correctly since the lifetime of the underlying data was too short,
same inputs would give random encryption keys.
Fixes#16668
This propagates errors from user-defined encoders up to IPC::Connection.
There, we currently just log the error, as we aren't in a position to
propagate it further (i.e. we are inside a deferred invocation).
In doing so, this removes all uses of the Encoder's stream operator,
except for where it is currently still used in the generated IPC code.
So the stream operator currently discards any errors, which is the
existing behavior. A subsequent commit will propagate the errors.
Currently, the stream operator overload hides most encoding errors. In
an effort to make IPC encoding fallible, this first replaces the Encoder
overloads with IPC::encode specializations. The return type is still a
boolean, a future commit will change it to ErrorOr.
Note that just like in the analogous decoder commit (9b48362), these
specializations must be defined at the namespace scope. Further, all
arithmetic specializations are now in one method.
