The logic in this script was *intended* to use the system's default
compiler if it was sufficiently new, and only start searching for the
latest installed if the default was not suitable.
However, the `cxx` program does not exist on Unixes, so the version
check always failed. We should be using the standard `c++` program name
instead.
After this change, the `CC` and `CXX` environment variables will have to
be used if someone wants to force a newer compiler version.
No behavior change. No measurable performance different either.
(I tried `hyperfine 'Build/lagom/bin/image --no-output foo.webp'`
for a few input images before and after this change, and I didn't
see a difference. I also tried if moving both
Gfx::CanonicalCode::read_symbol() and
Compress::CanonicalCode::read_symbol() inline, and that didn't
help either.)
* Matches how the loader is organized
* `compress_VP8L_image_data()` will grow longer when we add actual
compression
* Maybe someone wants to write a lossy compressor one day
No behavior change.
Nobody uses this functionality. I used this code on my old 2007 ICH7
test machine about a year ago, but bare metal is a small aspect of the
project, so it's safe to assume that nobody really tests this piece of
code.
Therefore, let's drop this for good and focus on more modern hardware.
Xcode clang doesn't understand the -std=c++23 spelling yet, and this
is what CMake's `set(CMAKE_CXX_STANDARD 23)` translates to too.
Unbreaks building with Xcode clang on macOS.
This allows main UI processes created while there is a currently
running one to request a new tab or a new window with the initial urls
provided on the command line. This matches (almost) the behavior of
Chromium and Firefox.
Add a new IPC protocol between two UI processes. The main UI process
will create an IPC server socket, while secondary UI processes will
connect to that socket and send over the URLs and action it wants the
main process to take.
It previously resided in LibWebView to hide the details of launching a
singleton process. That functionality now lives in LibCore. By moving
this to Ladybird, we will be able to register the process with the task
manager.
This just moves the code to launch a single process such as SQLServer to
LibCore. This will allow re-using this feature for other processes, and
will allow moving the launching of SQLServer to Ladybird.
This will be needed to collect statistics from processes that do not
have anything to do with LibWebView. The ProcessInfo structure must be
virtual to allow callers to add application-specific information.
On macOS, it's not trivial to get a Mach task port for your children.
This implementation registers the chrome process as a well-known
service with launchd based on its pid, and lets each child process
send over a reference to its mach_task_self() back to the chrome.
We'll need this Mach task port right to get process statistics.
On Serenity, it's not trivial to extract the peer pid from a socket that
is created by SystemServer and then passed to a forked service process.
This patch adds an API to let the WebContent process notify the UI
directly, which makes the WebContent process show up in the Serenity
port's TaskManagerWidget. It seems that we will need to do something of
this sort in order to properly gather metrics on macOS as well, due to
the way that self mach ports work.
