This file was formerly named `Libraries/LibCore/puff.c` and it was not
checked by `check-style.sh` because it only checks .h and .cpp files.
Since this file was not written by us, we shouldn't check its style.
This file was also causing our Travis builds to fail.
Now that we don't keep a C compiler around in the toolchain (to save
space) we can't have .c files in the build.
This reminds me that #362 exists and we should fix that at some point.
Empirically, every single push or PR has to download *and then upload*
about 3.6 GiB of "cache stuff", which takes up about 400 seconds:
https://travis-ci.com/github/SerenityOS/serenity/builds/177500795
On every single push/PR! No matter what!
Those 3.6 GB consist of:
- 3.2 GB Toolchain cache (around 260 MB per compressed item)
- 0.4 GB ccache, but is capped at 0.5 GB: https://travis-ci.com/github/BenWiederhake/serenity/builds/177528549
- (And 200 KB for some weird debian package? Dunno.)
Investigating in the size, the Toolchain consists mostly of *DEBUG SYMBOLS IN
THE COMPILER BINARIES* which comically misses the point. If we ever run into
compiler crashes, any stacktrace would be lost anyway as soon as the Travis VM
shuts down. Furthermore, Travis will only ever compile Serenity itself, and
Serenity forbids C in it's Contribution Guidelines. That's another 20 MB we
don't need to cache.
Stripping the binaries and deleting the C compiler reduces the uncompressed size
from 1200 MB down to 220 MB. The compressed size gets reduced from 260 MB to 70MB.
That's a reduction of 73%.
It'll take a while until the 'old' toolchains get deleted.
I guess it'll take less than a week.
From that point onward, the Travis cache will be 1.2 GB, consisting of:
- 0.7 GB Toolchain cache
- 0.5 GB ccache
- (And that weird 200 KB deb file)
If network speeds are linear, then this should reduce the "cache network
overhead time" from about 400 seconds to about 120 seconds.
tl;dr: Strip unnecessary debug infos, delete an unused files, and speed
everything up by two minutes. (Both Toolchain cache hits and Toolchain rebuilds!)
Uploading the cache takes several minutes. This gives us a handy way to tell
which parts the worst culprits are.
The Toolchain cache seems to be the worst offender by far, because the binary
size nearly doubled when we upgraded from gcc9 to gcc10.
We were masking the fragment offset bits incorrectly in the IPv4 header
sent out with fragments. This worked up to ~32KB but after that, things
would get very confused. :^)
Const pointers into the DOM was a nice idea, but in practice, there are
too many situations where the layout tree wants to some non-const thing
to the DOM.
ModularFunctions::random_number calls into AK::fill_with_random calls (on
Serenity) into arc4random_buf calls into Process::sys calls into
get_good_random_bytes, which is cryptographically secure.
Some of these don't just use the REG bits of the mod/rm byte
as slashes, but also the R/M bits to have up to 9 different
instructions per opcode/slash combination (1 opcode requires
that MOD is != 11, the other 8 have MODE == 11).
This is done by making the slashes table two levels deep for
these cases.
Some of this is cosmetic (e.g "FST st0" has no effect already,
but its bit pattern gets disassembled as "FNOP"), but for
most uses it isn't.
FSTENV and FSTCW have an extraordinary 0x9b prefix. This is
not yet handled in this patch.
I was a bit confused by the fact that a method named `build_system_menu()`
first enumerates a directory. Moving the app/category discovery to a dedicated
function that returns the GUI-relevant information makes this process a bit
less surprising.
As an added bonus, `g_app_category_menus` was actually only a temporary mapping,
and didn't need to be global. In theory, SystemMenu should use a handful fewer
of bytes now.
It doesn't make sense for a top-level menu to have an icon, however
we do not have dedicated classes to distinguish these.
Furthermore, the only other place to store an icon is MenuItem.
Storing it there would be highly confusing, as MenuItem-with-Action
then would have two icons: one in Action and one in MenuItem.
And because we need to be able to replace the icon during realization,
this would need to write-through to Action somehow.
That's why I went with Menu, not MenuItem.
This factors out icon realization into its own function, making it possible to
use the same code with other classes that have icon() and set_icon() methods.
