After 5ac57f9, we could no longer run "serenity.sh run lagom TestString"
because the TestString binary now lives in a subdirectory under
Build/lagom. Thus the existing method of running "$BUILD_DIR/TestString"
could not work.
This adds a "run-lagom-target" custom target to Lagom, to run a command
and pass arguments to that invocation. It turns out there really isn't a
"pretty" way of doing this with CMake or Ninja. But we can pass these as
environment variables for CMake to interpret. We just must be careful to
massage arguments into a CMake list.
This makes sure that the aarch64 disk image also contains the correct
dynamic shared objects, specifically libgcc_s.so.1, as that one is a
dynamic dependency of every aarch64 executable.
To unify the x86_64 and aarch64 code paths, this commit just installs
everything from the compilers lib directory into the disk image lib
directory. This also happens for the Clang toolchain. This copies a few
extra files related to libsupc++ and libstdc++, increasing the size of
the disk image by 1.6MB. However, we were already copying libstdc++.a
manually anyway.
For now, this is limited to strings that are 3 bytes or less. We can use
7 bytes on 64-bit platforms, but we do not yet assume 64-bit for Lagom
hosts (e.g. wasm).
When trying to figure out the correct implementation, we now have a very
strong distinction on plugins that are well suited for sniffing, and
plugins that need a MIME type to be chosen.
Instead of having multiple calls to non-static virtual sniff methods for
each Image decoding plugin, we have 2 static methods for each
implementation:
1. The sniff method, which in contrast to the old method, gets a
ReadonlyBytes parameter and ensures we can figure out the result
with zero heap allocations for most implementations.
2. The create method, which just creates a new instance so we don't
expose the constructor to everyone anymore.
In addition to that, we have a new virtual method called initialize,
which has a per-implementation initialization pattern to actually ensure
each implementation can construct a decoder object, and then have a
correct context being applied to it for the actual decoding.
In order to prevent this commit from having to refactor almost all of
Intl, the goal here is to update the internal parsing/canonicalization
of locales within LibLocale only. Call sites which are already equiped
to handle String and OOM errors do so, however.
...mostly.
This creates and uses an override for the `serenity_test()` function, so
that Lagom can make use of the existing `Tests/LibFoo/CMakeLists.txt`
files instead of having to GLOB for test source files and manually copy
any data files.
Some GLOBs remain but this is most of them.
Co-authored-by: Andrew Kaster <akaster@serenityos.org>
The macOS FileWatcher depends on macOS dispatch queues, which run on a
different thread than the Core::EventLoop. This implementation handles
filesystem events on its dispatch queue, then forwards the event back to
the main Core::EventLoop for notifying the FileWatcher owner.
This includes:
- Moving it from Bindings/ to HTML/
- Renaming it from LocationObject to Location
- Removing the manual definitions of the constructor and prototype
- Removing special handling of the Location interface from the bindings
generator
- Converting the JS_DEFINE_NATIVE_FUNCTIONs to regular functions
returning DeprecatedString instead of PrimitiveString
- Adding missing (no-op) setters for the various attributes, which are
expected to exist by the bindings generator
Case folding rules have a similar mapping style as special casing rules,
where one code point may map to zero or more case folding rules. These
will be used for case-insensitive string comparisons. To see how case
folding can differ from other casing rules, consider "ß" (U+00DF):
>>> "ß".lower()
'ß'
>>> "ß".upper()
'SS'
>>> "ß".title()
'Ss'
>>> "ß".casefold()
'ss'
And remove links that aren't adding much value but will often get out of
date (i.e. links to UCD files, which are already all listed in
unicode_data.cmake).
This implements FileWatcher using inotify filesystem events. Serenity's
InodeWatcher is remarkably similar to inotify, so this is almost an
identical implementation.
The existing TestLibCoreFileWatcher test is added to Lagom (currently
just for Linux).
This does not implement BlockingFileWatcher as that is currently not
used anywhere but on Serenity.
If USING_AK_GLOBALLY is not defined, the name IsLvalueReference might
not be available in the global namespace. Follow the pattern established
in LibTest to fully qualify AK types in macros to avoid this problem.
The old approach was basically a linear scan, which is slower than a
hash map for the currently 303 elements, as evidenced by the new
benchmark in TestCSSIDSpeed.
Before: Completed benchmark 'value_id_from_string' in 3238ms
After: Completed benchmark 'value_id_from_string' in 193ms
This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
This utility when given a .tff font provides options for disassembling:
- The 'fpgm' table, this a program that's run once when the font is
loaded. It's used to define instructions and functions used by used
by other programs.
- The 'prep' table, this is a general program that's run when ever
the font size (or other properties) changes.
- And the programs associated with any individual glyph.
The disassembly is printed in a format that matches the examples from:
https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions
I'm mainly adding this because I think it's neat to be able to look
at these things, and think it'll be helpful for debugging an
interpreter.
With this you can see that all of the LiberationSerif-XXX.tff fonts in
Serenity have these programs ready to go.
Currently, for each exposed interface, we generate one massive function
to create every Web constructor and prototype. In an effort to lazily
create these instead, this first step is to extract the creation of each
of these into its own method.
First, this generates a forwarding header for all IDL types. This is to
allow callers to remain unchanged without forcing them to include the
(very heavy) generated IDL headers. This header is included by LibWeb's
forwarding header.
Next, this defines a base template method on Web::Bindings::Intrinsics
to create a prototype/constructor pair. Specializations of this template
are now generated in a new .cpp file, IntrinsicDefinitions.cpp. The base
Intrinsics class is updated to use this new method, and will continue to
cache the result.
Last, some WebAssembly classes are updated to use this new mechanism.
They were using some ad hoc cache keys that are now in line with the
generated specializations.
That one massive function is still used to invoke these specializations,
so they are not lazy as of this commit.
Since AK can't refer to LibUnicode directly, the strategy here is that
if you need case transformations, you can link LibUnicode and receive
them. If you try to use either of these methods without linking it, then
you'll of course get a linker error (note we don't do any fallbacks to
e.g. ASCII case transformations). If you don't need these methods, you
don't have to link LibUnicode.
Nobody tests this network card as the person who added it, Jean-Baptiste
Boric (known as boricj) is not an active contributor in the project now.
After a discussion with him on the Discord server, we agreed it's for
the best to remove the driver, as for two reasons:
- The original author (boricj) agreed to do this, stating that he will
not be able to test the driver anymore after his Athlon XP machine is
no longer supported after the removal of the i686 port.
- It was agreed that the NE2000 network card family is far from the
ideal hardware we would want to support, similarly to the RTL8139 that
got removed recently for almost the same reason.
Previously, we had some broken cross-manpage links on the website after
the introduction of subsections. This is fixed by simply always using an
absolute path (leading '/') for links, making all images, icons and page
links work in all subsections.
Unfortunately, this change means that navigating the website build while
opening the files in the browser directly will no longer work. However,
a local static server such as `python -m http.server 8080` in the
output/ directory will work just fine for testing.
This will allow using images in manpages elsewhere in the future without
adjusting the PNG copying command.
rsync unfortunately cannot place all files into the root folder when
receiving a list of files via --files-from=-.
Nobody tests this network card, and the driver has bugs (see the issue
https://github.com/SerenityOS/serenity/issues/10198 for more details),
so it's almost certain that this happened due to code being rotting when
there's simply no testing of it.
Essentially this has been determined to be dead-code so this is the most
important reason to drop this code. Another good reason to do so is
because the RTL8139 only supports Fast Ethernet connections (10/100
Megabits per second), and is considered obsolete even for bare metal
setups.
This is required for me to be able to build both Serenity and
Ladybird from the same repo. Without this the two builds seem to
stomp on each other, then fail to link.
Generic PR actions include opening a PR, submit review comments, adding
new commits, etc. This prevents the reviewer and PR submitter from
having to manually bounce the labels back and forth in the general
case. The reviewer also may not have permission to set labels, meaning
the reviewer won't be able to update the labels accordingly themselves.
This does not handle more subjective labels such as pr-is-blocked and
pr-unclear. Unfortunately, there does not seem to be a GitHub Actions
trigger for when a PR has merge conflicts, so the pr-has-conflicts
label cannot be automatically applied.
Co-authored-by: kleines Filmröllchen <filmroellchen@serenityos.org>
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 )
