Calculating tiled and miximized window frame have a lot in common. In
fact, we can look at maximized window state as a special case of the
tile type. It simplifies the code since there is a lot of cases when
we take an action only if the window is maximized or tiled.
The SB16 card driver doesn't swallow more than 4096 bytes of data at
once, so instead of asserting just return ENOSPC for now.
To test this, either play normal sound or just this (very!) loud noise:
dd if=/dev/random of=/dev/audio/0 bs=4096
For now, just use the first audio channel in the /dev/audio directory.
In the future we can add support for watching and loading other channels
so we can route audio to multiple sound cards on the system.
We have 3 new components:
1. The AudioManagement singleton. This class like in other subsystems,
is responsible to find hardware audio controllers and keep a reference
to them.
2. AudioController class - this class is the parent class for hardware
controllers like the Sound Blaster 16 or Intel 82801AA (AC97). For now,
this class has simple interface for getting and controlling sample rate
of audio channels, as well a write interface for specific audio channel
but not reading from it. One AudioController object might have multiple
AudioChannel "child" objects to hold with reference counting.
3. AudioChannel class - this is based on the CharacterDevice class, and
represents hardware PCM audio channel. It facilitates an ioctl interface
which should be consistent across all supported hardware currently.
It has a weak reference to a parent AudioController, and when trying to
write to a channel, it redirects the data to the parent AudioController.
Each audio channel device should be added into a new directory under the
/dev filesystem called "audio".
Since we're in an IRQ each of these evaluate_block_conditions() calls
enqueues a new deferred call, so to save on some space in the deferred
call queue let's just do it once.
It's really annoying to write `console.log(JSON.stringify(something))`
in scripts, and the output is less than easily readable.
This exposes the existing `print(Value)` function into the JS world, and
allows us to write `print(something)` and get a neat representation in
the console.
Emitting tokens on EOF caused an infinite loop, freezing the app, which
could be a bit annoying when writing an HTML comment at the end of
the file in Text Editor. :^)
Commit b193351a99 caused the HTML comments to flash when changing
the text cursor. Also, when double-clicking on a comment, the selection
started from the beginning of the file instead.
The following message was displaying when `TOKENIZER_TRACE_DEBUG`
was enabled:
(Tokenizer::nth_last_position) Invalid position requested: 4th-last
of 4. Returning (0-0).
Changing the `nth_last_position` to 3 fixes this. I'm guessing that's
because the parser is at that moment on the second hyphen of the `<!--`
string, so it has to go back only by three characters.
Because the wake pipe is thread-local, it was previously not possible
to wake an event loop across a thread. Therefore, this commit
rearchitects event loop waking by making the wake function a member of
the event loop itself and having it keep a pointer to its thread's wake
pipe. The global wake() function calls wake on the current thread's
event loop.
This also fixes a bug in BackgroundAction: it should wake the event loop
it was created on, instead of the current thread's event loop.
Previously, event loop stacks on non-main threads would always crash
because the condition for "am I the lowest-stacked loop" was still
"am I the main loop", which of course is no longer sensible. A simple
switch to `is_instantiated` fixes this.
When triple clicking a line in the terminal the selection will span the
whole line. However, after dragging down to lines above/below the
selection will stop at the cursor.
Instead, the expected functionality of triple clicking and dragging is
to select the whole line and any whole lines dragged to after the triple
click.
Previously, the triple line counter would get reset as soon as the whole
line was selected. This patch resets the m_triple_click_timer in the
mouse up event, so that the triple click selecting functionality is
maintained during the entire click event and terminated when the event
is over.
This matches the likes of the adopt_{own, ref}_if_nonnull family and
also frees up the name to allow us to eventually add OOM-fallible
versions of these functions.
Now that expression evaluation can use TRY, we can allow binary operator
methods to fail as well. This also fixes a few instances of converting a
Value to a double when we meant to convert to an integer.
If a tuple has a single value, perform a comparison using that singular
value. This allows, for example, comparisons of the form "(1) < 4",
where (1) is a single element tuple.
There's a fair amount of VERIFY/TODO calls in LibSQL that will crash the
SQL server if we hit an unimplemented feature or some bug. Restart the
server if this happens to help with debugging / development.
Move the definitions for maximum argument and environment size to
Process.h from execve.cpp. This allows sysconf(_SC_ARG_MAX) to return
the actual argument maximum of 128 KiB to userspace.
Error codes can leak information about veiled paths, if the path
resolution fails with e.g. EACCESS.
This is non-trivial to fix, as there is a group of error codes we want
to propagate to the caller, such as ENOMEM.
VirtualFileSystem::mkdir() relies on resolve_path() returning an error,
since it is only interested in the out_parent passed as a pointer. Since
resolve_path_without_veil returns an error, no process veil validation
is done by resolve_path() in that case. Due to this problem, mkdir()
should use resolve_path_without_veil() and then manually validate if the
parent directory of the to-be-created directory is unveiled with 'c'
permissions.
This fixes a bug where the mkdir syscall would not respect the process
veil at all.
Previously, VirtualFileSystem::resolve_path() could return a non-null
RefPtr<Custody>* out_parent even if the function errored because the
path has been veiled.
If code relies on recieving the parent custody even if the path is
veiled, it should just call resolve_path_without_veil and do the veil
validation manually. This is because it could be that the parent is
unveiled but the child isn't or the other way round.
