When volume is zero it is not necessary to go through the mixing loop.
The zero-filled buffer can be written directly to the device, instead,
similar to the muted case. Tested by using the piano app and the main
volume control.
C++20 can automatically synthesize `operator!=` from `operator==`, so
there is no point in writing such functions by hand if all they do is
call through to `operator==`.
This fixes a compile error with compilers that implement P2468 (Clang
16 currently). This paper restores the C++17 behavior that if both
`T::operator==(U)` and `T::operator!=(U)` exist, `U == T` won't be
rewritten in reverse to call `T::operator==(U)`. Removing `!=` operators
makes the rewriting possible again.
See https://reviews.llvm.org/D134529#3853062
Previously each emoji had its own symbol in the library which was then
referred to by another symbol. This caused thousands of avoidable data
relocations at load time.
This saves about 122kB RAM for each process which uses LibUnicode.
Previously the s_decomposition_mappings variable would refer to other
data in s_decomposition_mappings_data. This would cause thousands of
avoidable relocations at load time.
This saves about 128kB RAM for each process which uses LibUnicode.
Should use the min_content_height function for calculating the height of
content. Thanks to previous commits, are able to use the width of the
column for this calculation.
Should use AvailableSpace to get the grid width instead of
box_state.content_width().
This change was imposed on me by the compiler as in a future commit I
will remove the only reference to the available_space parameter.
As per the spec, it seems that the size of the columns of the grid
should be calculated first, and then the sizes of the rows. This commit
reorders the code for the sizing of the grid to match the spec.
This will be used in a future commit so as to calculate the height of a
row based on the resolved final width of a column.
Previously were not passing along any information to the children
of the grid, as were simply passing the same AvailableSpace that was
received for the grid itself. Now, each child is given an available
space in accordance with the layout of the grid.
This is an editorial change to the ECMA-402 spec. See:
46aa5cc
Also add an ECMA-402 spec link to the DefaultTimeZone implementation, as
that definition supersedes ECMA-262.
This adds a test of a conic-gradient() with just a center position
and no starting angle.
This also adds a gradient that gives each quadrant a different color,
this is very sensitive to the center position being correct.
This makes the center position the center of the pixel rather than
the top left corner (which fixes some small artifacts on a few
gradients).
This also now floors the angle used to sample from the gradient line,
this avoids the colors diverging the further away from the center you
get (which is noticeable on hard-edge gradients).
This happens in two ways:
1. LibCore now has two new methods for creating Jails and attaching
processes to a Jail.
2. We introduce 3 new utilities - lsjails, jail-create and jails-attach,
which list jails, create jails and attach processes to a Jail,
respectively.
This method was taken from the pls utility and its purpose is to execute
a given command with all the required requirements such as providing a
suitable exec environment.
Our implementation for Jails resembles much of how FreeBSD jails are
working - it's essentially only a matter of using a RefPtr in the
Process class to a Jail object. Then, when we iterate over all processes
in various cases, we could ensure if either the current process is in
jail and therefore should be restricted what is visible in terms of
PID isolation, and also to be able to expose metadata about Jails in
/sys/kernel/jails node (which does not reveal anything to a process
which is in jail).
A lifetime model for the Jail object is currently plain simple - there's
simpy no way to manually delete a Jail object once it was created. Such
feature should be carefully designed to allow safe destruction of a Jail
without the possibility of releasing a process which is in Jail from the
actual jail. Each process which is attached into a Jail cannot leave it
until the end of a Process (i.e. when finalizing a Process). All jails
are kept being referenced in the JailManagement. When a last attached
process is finalized, the Jail is automatically destroyed.
