Before, TEST_MAIN used to return the return value of TestSuite::main()
function (which returns the number of test cases that did not pass, so
it can be >=256) directly.
The run-tests utility determines the success / failure of a test suite
binary by examining its (or i.e. TEST_MAIN's) exit status.
But as exit status values are supposed to be between 0 and 255, values
>=256 will get wrapped around (modulo 256), converting a return value of
256 to 0.
So, in a rare case where exactly 256 test cases are failing in your test
suite, run-tests utility will display that the test suite passed without
any failures.
Now, TEST_MAIN just returns 0 if all of the test cases pass and returns
1 otherwise.
The former automatically adapts the prefix to binary and octal
output, and is what we already use in the majority of cases.
Patch generated by:
rg -l '0x\{' | xargs sed -i '' -e 's/0x{:/{:#/'
I ran it 4 times (until it stopped changing things) since each
invocation only converted one instance per line.
No behavior change.
Before, we used to reject profiles where the creation datetime was
invalid per spec. But invalid dates happen in practice (most commonly,
all fields set to 0). They don't affect profile conversion at all,
so be lenient about this, in exchange for slightly more wordy code
in the places that want to show the creation datetime.
Fixes a crash rendering page 2 of
https://fredrikbk.com/publications/copy-and-patch.pdf
This allows the user to pass very specific values instead of a u64 value
that is later cast to the underlying type.
The change also adds support for passing v128 values:
- v(i64.const 4) (splat 4)
- v128.const 0x4 (just a few bits specificed, everything else = 0)
Previously, the check for `.html` meant that `.svg` tests were excluded.
This led to a few `.svg` with missing or bit-rotted expectations, which
have now been added/updated.
Before this change, the rebaseline script would generate reference
based on 'about:blank' (at least running it on my macOS system).
This commit allows 'about:blank' through the assertion and only dumps
the layout tree when theloaded URL matches the one we are interested
in.
Along with this, Port.h is include which helps generalising common
information for the port package, like it's name and version. With
SemVer complaint versions, it is possible to show positive change
(upgrade) or negative change (downgrade) in the installed ports.
However, for some non-complaint versions (eg. using git commit hash),
non-equality (`!=`) is used to notify upgrade. Since there is no
algorithm (without git history) to check the order of commits, it is
not possible to inform whether it is an upgrade or downgrade.
- Add interactive flag which tells `cp` to prompt before overwriting
files
- Accept 'yes', 'no', 'n', and 'y' as input, all other inputs will
result in the prompt being shown again
Instead of polluting global namespace with definitions from
libkern/OSByteOrder.h and machine/endian.h on MacOS, just use AK
functions for conversions.
This is useful for working with CMYK jpegs extracted from PDFs
by mutool. CMYK channels for jpegs in PDFs are inverted compared to
CMYK channels in standalone jpegs (!), and mutool doesn't compensate
for that.
You can now do:
mutool extract ~/Downloads/0000/0000711.pdf 461
Followed by:
Build/lagom/bin/image -o out.png \
--invert-cmyk \
--assign-color-profile \
Build/lagom/Root/res/icc/Adobe/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
cmyk.jpg
Doesn't exactly roll off the keyboard, but at least it's possible.
(We should probably add an implicit default CMYK color profile if
the input file doesn't have one, and assume conversion to sRGB when
saving to a format that can only store RGB.)
The IPC layer between chromes and LibWeb now understands that multiple
top level traversables can live in each WebContent process.
This largely mechanical change adds a billion page_id/page_index
arguments to make sure that pages that end up opening new WebViews
through mechanisms like window.open() still work properly with those
extra windows.
These were here due to the prefix-less name conflicting with a local
bool, but now that options are in a struct that's no longer a problem.
No behavior change.
`image` can't transform from RGB to CMYK yet, so the only way to
do this is by having a CMYK input.
For example, this works now (and it does a full decode and re-encode):
Build/lagom/bin/image -o out.jpg \
Tests/LibGfx/test-inputs/jpg/buggie-cmyk.jpg
Using this to convert `.pam` files written by `mutool extract`
to jpegs is a somewhat convenient method of looking at these
.pam files.
Previously `image -o foo.asdf foo.png` would create a 0-byte foo.asdf
before complaining that it doesn't know how to write .asdf images.
(Lifetimes of temporaries are extended to the end of the full
expresion, so this is fine.)
Previously, we ignored the -p argument if it was specified. This
would resort in a crash because final_target_directory wasn't given a
value.
This snapshot does away with giving this variable an Optional<> and
just has the -p argument be its default value.
We use these canonicalized_path variables as StringViews, so it doesn't
matter if they are a String or ByteString. And they're paths so
shouldn't be String anyway.
Every single of images's functions then go ahead and error out on
CMYKBitmaps for now.
(Alternatively, we could make them the low-quality CMYK->RGB
conversion that previously happened implicitly, but let's go
with this for now.)
(With this structure, we could also do something smarter for
Vector images in the future.)
Here's how this looks:
% Build/lagom/bin/image \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: Can't save CMYK bitmaps yet, convert to RGB first
with --convert-to-color-profile
% Build/lagom/bin/image \
--convert-to-color-profile serenity-sRGB.icc \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: No source color space embedded in image.
Pass one with --assign-color-profile.
% Build/lagom/bin/image \
--assign-color-profile path/to/CMYK/USWebCoatedSWOP.icc \
--convert-to-color-profile serenity-sRGB.icc \
-o out.png Tests/LibGfx/test-inputs/jpg/ycck-2111.jpg
Runtime error: Psych, can't convert CMYK bitmaps yet either
As usual, serenity-sRGB.icc is from
`Build/lagom/bin/icc -n sRGB --reencode-to serenity-sRGB.icc` and
the adobe cmyk profiles are available at
https://www.adobe.com/support/downloads/iccprofiles/iccprofiles_win.html
which ultimately leads to:
https://download.adobe.com/pub/adobe/iccprofiles/win/AdobeICCProfilesCS4Win_end-user.zip
This makes it easier to move the color space conversion code out
into a helper function, and will be used to pass around CMYK bitmaps.
No behavior change.
...instead of warn() + manual return.
Before:
% Build/lagom/bin/image -o out.asdf in.png
can only write .bmp, .png, .ppm, and .qoi
Now:
% Build/lagom/bin/image -o out.asdf in.png
Runtime error: can only write .bmp, .png, .ppm, and .qoi
That doesn't look worse, and it's less code (and makes moving the
code into helper functions easier).
The -p flag is equivalent to the previous behavior: outputting the
uptime in a human-readable form.
We don't seem to expose the number of online users or the load averages,
so those sections are missing from the output compared to those OSes.
We now split up symbols into zero-sized symbols that label single
instructions (no need to separate them by newlines; they are used for
jump labels and relocation targets within a larger block of code) and
ranged symbols that label functions. Empty symbols are discarded since
at least RISC-V ELF files contain quite a few of those. Zero-sized
symbols and ranged symbols are handled almost the same, but this way we
can make sure that zero-sized symbols don't interfere with ranged
symbol's newline separation logic. For zero-sized symbols, the "symbol
contains address" logic is updated so they actually contain the one
address they're pointing at, fixing the bug with many "dangling"
zero-sized symbols after a function that contained them. Zero-sized
labels are also no longer printed as a start-end range, since that is
unnecessary visual noise.
This is an option supported by coreutils, so we might as well support
it too.
It allows users to wrap their encoded output after the "column" value
they provide.
This commit also has the Markdown look more like what we see
when running ArgsParser::print_usage_markdown() (and it fixes some
of the examples).
